From: Janis Papanagnou on
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
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
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
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
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