How to determine integer?
in [Shell]
|
Prev: Parsing "for" clause
Next: read multiple fields separated by : and fields separated by , in loop stored in $var
From: Janis Papanagnou on 13 Mar 2010 15:17 Francis Moreau wrote: > On Mar 13, 12:39 pm, Stephane CHAZELAS <stephane_chaze...(a)yahoo.fr> > wrote: >> 2010-03-13, 10:42(+00), SM: >> [...] >> >>> I came across this kind of hack: >>> is_int() { >>> printf "%d" $1 > /dev/null 2>&1 >> missing quotes above. >> >>> return $? >> redundant and missing quotes. >> > > why are quotes missing ? In the first case (printf) any kind of argument may be passed and create any amount of trouble or inaccuracy depending on the passed argument; it's the word splitting issue. In the second case $? the quotes are not necessary since $? will contain a numerical value.[*] But, as said, the return statement is redundant because the function will return the return code of the last executed command anyway. There are yet more issues in the posted suggestion, though; like the inappropriate use of the read command. Janis [*] I *suspect* - since the variable expansion is in the context of a shell construct (return) - that it might not even be necessary to quote it even if you're returning a variable with a value containing spaces; which makes no sense anyway since a function return value in shell is just a small integer.
From: Francis Moreau on 13 Mar 2010 15:26 On Mar 13, 7:11 pm, Stephane CHAZELAS <stephane_chaze...(a)yahoo.fr> wrote: > 2010-03-13, 05:16(-08), Francis Moreau: > > > > > > > On Mar 13, 12:39 pm, Stephane CHAZELAS <stephane_chaze...(a)yahoo.fr> > > wrote: > >> 2010-03-13, 10:42(+00), SM: > >> [...] > > >> > I came across this kind of hack: > > >> > is_int() { > >> > printf "%d" $1 > /dev/null 2>&1 > > >> missing quotes above. > > >> > return $? > > >> redundant and missing quotes. > > > why are quotes missing ? > > Leaving a variable expansion unquoted, in the shell, means > asking for the expansion to be split (according to complicated > rules involving the $IFS variable) and each resulting word to be > subject to filename generation. > > For instance if the first positional parameter contains " 1 * 2" > and with the default value of IFS, printf will not be passed one > argument containing " 1 * 2" but one containing "1", then as > many as there are non-dot files in the current directory, and > then 2. > I was actually asking about "return $?" expression.
From: pk on 13 Mar 2010 15:18 Janis Papanagnou wrote: >>>> return $? >>> redundant and missing quotes. >>> >> >> why are quotes missing ? > > In the first case (printf) any kind of argument may be passed and > create any amount of trouble or inaccuracy depending on the passed > argument; it's the word splitting issue. In the second case $? the > quotes are not necessary since $? will contain a numerical value.[*] >[snip] > [*] I *suspect* - since the variable expansion is in the context of > a shell construct (return) - that it might not even be necessary to > quote it even if you're returning a variable with a value containing > spaces; which makes no sense anyway since a function return value in > shell is just a small integer. I think what he meant is that if, for example, IFS is "1" an unquoted $? might not do what one expects. But I agree that is hardly a problem in the vast majority of cases. Still, quoting does not hurt.
From: Francis Moreau on 13 Mar 2010 15:27 On Mar 13, 9:17 pm, Janis Papanagnou <janis_papanag...(a)hotmail.com> wrote: > Francis Moreau wrote: > > On Mar 13, 12:39 pm, Stephane CHAZELAS <stephane_chaze...(a)yahoo.fr> > > wrote: > >> 2010-03-13, 10:42(+00), SM: > >> [...] > > >>> I came across this kind of hack: > >>> is_int() { > >>> printf "%d" $1 > /dev/null 2>&1 > >> missing quotes above. > > >>> return $? > >> redundant and missing quotes. > > > why are quotes missing ? > > In the first case (printf) any kind of argument may be passed and > create any amount of trouble or inaccuracy depending on the passed > argument; it's the word splitting issue. In the second case $? the > quotes are not necessary since $? will contain a numerical value.[*] I was asking about the second case, which doesn't seem to need any quotes (as you said).
From: Janis Papanagnou on 13 Mar 2010 15:51
pk wrote: > Janis Papanagnou wrote: > >>>>> return $? >>>> redundant and missing quotes. >>>> >>> why are quotes missing ? >> In the first case (printf) any kind of argument may be passed and >> create any amount of trouble or inaccuracy depending on the passed >> argument; it's the word splitting issue. In the second case $? the >> quotes are not necessary since $? will contain a numerical value.[*] >> [snip] >> [*] I *suspect* - since the variable expansion is in the context of >> a shell construct (return) - that it might not even be necessary to >> quote it even if you're returning a variable with a value containing >> spaces; which makes no sense anyway since a function return value in >> shell is just a small integer. > > I think what he meant is that if, for example, IFS is "1" an unquoted $? > might not do what one expects. But I agree that is hardly a problem in the > vast majority of cases. Still, quoting does not hurt. That's correct. Haven't thought about the pathological and made up case that, for one, one would intentionally set the IFS to 1, but not reset it when necessary. Gee! I think that the main point is that you rarely need $? at all. In this case it was redundant, and in most other cases I see it used just like some_command ; if [ $? -eq 0 ] ; then # etc. where you may prefer to write if some_command ; then # etc. The $? is interesting if you want to distinguish returned status; case $? in : esac and this is again an application in a shell construct context where you don't need the quotes. Janis |