git-bisect: weird usage of read(1)

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

git-bisect: weird usage of read(1)

Francis Moreau
Hello

I found this in git bisect:

              printf >&2 'Are you sure [Y/n]? '
              case "$(read yesno)" in [Nn]*) exit 1 ;; esac

which looks very weird since read(1) returns a status and not the
string reads from std input.

Am I missing something ?

Thanks
--
Francis
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: git-bisect: weird usage of read(1)

Johannes Schindelin
Hi,

On Mon, 11 Aug 2008, Francis Moreau wrote:

> I found this in git bisect:
>
>               printf >&2 'Are you sure [Y/n]? '
>               case "$(read yesno)" in [Nn]*) exit 1 ;; esac
>
> which looks very weird since read(1) returns a status and not the
> string reads from std input.
>
> Am I missing something ?

Yes.  "$()" does not return the status, but the output.

Ciao,
Dscho

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: git-bisect: weird usage of read(1)

Mikael Magnusson
2008/8/11 Johannes Schindelin <[hidden email]>:

> Hi,
>
> On Mon, 11 Aug 2008, Francis Moreau wrote:
>
>> I found this in git bisect:
>>
>>               printf >&2 'Are you sure [Y/n]? '
>>               case "$(read yesno)" in [Nn]*) exit 1 ;; esac
>>
>> which looks very weird since read(1) returns a status and not the
>> string reads from std input.
>>
>> Am I missing something ?
>
> Yes.  "$()" does not return the status, but the output.

But there is no output, since read doesn't print anything...
case "$(read yesno; echo $yesno)" in [Nn]*) could work, but looks
a bit strange. read yesno; case $yesno in [Nn]*) would be the usual
way to do things i think?

--
Mikael Magnusson
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: git-bisect: weird usage of read(1)

Francis Moreau
In reply to this post by Johannes Schindelin
Hello

On Mon, Aug 11, 2008 at 4:15 PM, Johannes Schindelin
<[hidden email]> wrote:

> Hi,
>
> On Mon, 11 Aug 2008, Francis Moreau wrote:
>
>> I found this in git bisect:
>>
>>               printf >&2 'Are you sure [Y/n]? '
>>               case "$(read yesno)" in [Nn]*) exit 1 ;; esac
>>
>> which looks very weird since read(1) returns a status and not the
>> string reads from std input.
>>

sorry I should have said that there's a status but no output...

>> Am I missing something ?
>
> Yes.  "$()" does not return the status, but the output.
>

But what's the output in that case ?

--
Francis
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: git-bisect: weird usage of read(1)

Reece Dunn
2008/8/11 Francis Moreau <[hidden email]>:

> Hello
>
> On Mon, Aug 11, 2008 at 4:15 PM, Johannes Schindelin
> <[hidden email]> wrote:
>> Hi,
>>
>> On Mon, 11 Aug 2008, Francis Moreau wrote:
>>
>>> I found this in git bisect:
>>>
>>>               printf >&2 'Are you sure [Y/n]? '
>>>               case "$(read yesno)" in [Nn]*) exit 1 ;; esac
>>>
>>> which looks very weird since read(1) returns a status and not the
>>> string reads from std input.
>>>
>
> sorry I should have said that there's a status but no output...
>
>>> Am I missing something ?
>>
>> Yes.  "$()" does not return the status, but the output.
>>
>
> But what's the output in that case ?

Using cygwin+bash, I get:

$ echo $(read yesno)
n

$ echo $(read yesno; echo $yesno)
n
n
$ $(read yesno) && echo yes || echo no
n
yes
$ $(read yesno) && echo yes || echo no
y
yes
$ case "$(read yesno)" in [Nn]*) echo "no" ;; esac
n
$ case "$(read yesno)" in [Nn]*) echo "no" ;; esac
y
$ case "$(read yesno; echo $yesno)" in [Nn]*) echo "no" ;; esac
n
no
$ case "$(read yesno; echo $yesno)" in [Nn]*) echo "no" ;; esac
y

So

>>>               case "$(read yesno)" in [Nn]*) exit 1 ;; esac

does not work as expected. Replacing this with

               case "$(read yesno; echo $yesno)" in [Nn]*) exit 1 ;; esac

would work as intended, as Mikael has pointed out.

- Reece
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: git-bisect: weird usage of read(1)

René Scharfe
In reply to this post by Francis Moreau
Francis Moreau schrieb:
> I found this in git bisect:
>
>               printf >&2 'Are you sure [Y/n]? '
>               case "$(read yesno)" in [Nn]*) exit 1 ;; esac
>
> which looks very weird since read(1) returns a status and not the
> string reads from std input.

Good catch.  You need to press Ctrl-C in order to exit, answering "no"
means the same as "yes" here -- not very nice.  Care to send a patch?

Thanks,
René
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: git-bisect: weird usage of read(1)

Francis Moreau
In reply to this post by Reece Dunn
On Mon, Aug 11, 2008 at 5:59 PM, Reece Dunn <[hidden email]> wrote:
> $ $(read yesno) && echo yes || echo no
> n
> yes
> $ $(read yesno) && echo yes || echo no
> y
> yes

funny, seeing these 2 cases I'm wondering why Bash is not complaining...

--
Francis
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: git-bisect: weird usage of read(1)

Reece Dunn
2008/8/11 Francis Moreau <[hidden email]>:
> On Mon, Aug 11, 2008 at 5:59 PM, Reece Dunn <[hidden email]> wrote:
>> $ $(read yesno) && echo yes || echo no
>> n
>> yes
>> $ $(read yesno) && echo yes || echo no
>> y
>> yes
>
> funny, seeing these 2 cases I'm wondering why Bash is not complaining...

I don't know; it could be an issue with cygwin.

I'll try it on a Linux box later and post the results then for comparison.

- Reece
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: git-bisect: weird usage of read(1)

Francis Moreau
On Mon, Aug 11, 2008 at 6:26 PM, Reece Dunn <[hidden email]> wrote:

> 2008/8/11 Francis Moreau <[hidden email]>:
>> On Mon, Aug 11, 2008 at 5:59 PM, Reece Dunn <[hidden email]> wrote:
>>> $ $(read yesno) && echo yes || echo no
>>> n
>>> yes
>>> $ $(read yesno) && echo yes || echo no
>>> y
>>> yes
>>
>> funny, seeing these 2 cases I'm wondering why Bash is not complaining...
>
> I don't know; it could be an issue with cygwin.
>
> I'll try it on a Linux box later and post the results then for comparison.
>

I got the same result on Linux...

--
Francis
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: git-bisect: weird usage of read(1)

Petr Baudis
In reply to this post by Reece Dunn
On Mon, Aug 11, 2008 at 04:59:32PM +0100, Reece Dunn wrote:
> >> On Mon, 11 Aug 2008, Francis Moreau wrote:
> >>>               case "$(read yesno)" in [Nn]*) exit 1 ;; esac
>
> does not work as expected. Replacing this with
>
>                case "$(read yesno; echo $yesno)" in [Nn]*) exit 1 ;; esac
>
> would work as intended, as Mikael has pointed out.

  Wouldn't it be more elegant to

        case "$(head -n 1)" in [Nn]*) exit 1 ;; esac

                                Petr "Pasky" Baudis
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: git-bisect: weird usage of read(1)

René Scharfe
Petr Baudis schrieb:

> On Mon, Aug 11, 2008 at 04:59:32PM +0100, Reece Dunn wrote:
>>>> On Mon, 11 Aug 2008, Francis Moreau wrote:
>>>>>               case "$(read yesno)" in [Nn]*) exit 1 ;; esac
>> does not work as expected. Replacing this with
>>
>>                case "$(read yesno; echo $yesno)" in [Nn]*) exit 1 ;; esac
>>
>> would work as intended, as Mikael has pointed out.
>
>   Wouldn't it be more elegant to
>
> case "$(head -n 1)" in [Nn]*) exit 1 ;; esac

Only if head is a built-in, otherwise you fork needlessly.  Not that
this is a performance critical part, but I wouldn't call it "elegant".

What's wrong with the following variant, already used a few lines up in
the file?

        read yesno
        case "$yesno" in [Nn]*) exit 1 ;; esac

René
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: git-bisect: weird usage of read(1)

Petr Baudis
On Mon, Aug 11, 2008 at 07:01:15PM +0200, René Scharfe wrote:

> Petr Baudis schrieb:
> > On Mon, Aug 11, 2008 at 04:59:32PM +0100, Reece Dunn wrote:
> >>>> On Mon, 11 Aug 2008, Francis Moreau wrote:
> >>>>>               case "$(read yesno)" in [Nn]*) exit 1 ;; esac
> >> does not work as expected. Replacing this with
> >>
> >>                case "$(read yesno; echo $yesno)" in [Nn]*) exit 1 ;; esac
> >>
> >> would work as intended, as Mikael has pointed out.
> >
> >   Wouldn't it be more elegant to
> >
> > case "$(head -n 1)" in [Nn]*) exit 1 ;; esac
>
> Only if head is a built-in, otherwise you fork needlessly.  Not that
> this is a performance critical part, but I wouldn't call it "elegant".

Ok, exec head -n 1. ;) And yes, I know... I guess I've just spent too
much time perl-golfing lately.

> What's wrong with the following variant, already used a few lines up in
> the file?
>
> read yesno
> case "$yesno" in [Nn]*) exit 1 ;; esac

Nothing wrong with this one, of course.

--
                                Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: git-bisect: weird usage of read(1)

Francis Moreau
In reply to this post by René Scharfe
On Mon, Aug 11, 2008 at 6:18 PM, René Scharfe
<[hidden email]> wrote:

> Francis Moreau schrieb:
>> I found this in git bisect:
>>
>>               printf >&2 'Are you sure [Y/n]? '
>>               case "$(read yesno)" in [Nn]*) exit 1 ;; esac
>>
>> which looks very weird since read(1) returns a status and not the
>> string reads from std input.
>
> Good catch.  You need to press Ctrl-C in order to exit, answering "no"
> means the same as "yes" here -- not very nice.  Care to send a patch?
>

done.

--
Francis
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: git-bisect: weird usage of read(1)

Junio C Hamano
In reply to this post by René Scharfe
René Scharfe <[hidden email]> writes:

> Petr Baudis schrieb:
>> On Mon, Aug 11, 2008 at 04:59:32PM +0100, Reece Dunn wrote:
>>>>> On Mon, 11 Aug 2008, Francis Moreau wrote:
>>>>>>               case "$(read yesno)" in [Nn]*) exit 1 ;; esac
>>> does not work as expected. Replacing this with
>>>
>>>                case "$(read yesno; echo $yesno)" in [Nn]*) exit 1 ;; esac
>>>
>>> would work as intended, as Mikael has pointed out.
>>
>>   Wouldn't it be more elegant to
>>
>> case "$(head -n 1)" in [Nn]*) exit 1 ;; esac
>
> Only if head is a built-in, otherwise you fork needlessly.  Not that
> this is a performance critical part, but I wouldn't call it "elegant".
>
> What's wrong with the following variant, already used a few lines up in
> the file?
>
> read yesno
> case "$yesno" in [Nn]*) exit 1 ;; esac

That's the right way to spell it.  Sorry, I must have been too tired
when I did this.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: git-bisect: weird usage of read(1)

Francis Moreau
On Mon, Aug 11, 2008 at 8:59 PM, Junio C Hamano <[hidden email]> wrote:

> René Scharfe <[hidden email]> writes:
>
>> Petr Baudis schrieb:
>>> On Mon, Aug 11, 2008 at 04:59:32PM +0100, Reece Dunn wrote:
>>>>>> On Mon, 11 Aug 2008, Francis Moreau wrote:
>>>>>>>               case "$(read yesno)" in [Nn]*) exit 1 ;; esac
>>>> does not work as expected. Replacing this with
>>>>
>>>>                case "$(read yesno; echo $yesno)" in [Nn]*) exit 1 ;; esac
>>>>
>>>> would work as intended, as Mikael has pointed out.
>>>
>>>   Wouldn't it be more elegant to
>>>
>>>      case "$(head -n 1)" in [Nn]*) exit 1 ;; esac
>>
>> Only if head is a built-in, otherwise you fork needlessly.  Not that
>> this is a performance critical part, but I wouldn't call it "elegant".
>>
>> What's wrong with the following variant, already used a few lines up in
>> the file?
>>
>>       read yesno
>>       case "$yesno" in [Nn]*) exit 1 ;; esac
>
> That's the right way to spell it.  Sorry, I must have been too tired
> when I did this.
>
>
>

I sent a patch to fix that way already

Cheers.
--
Francis
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html