Change in behavior of bash / if [

Change in behavior of bash / if [

[Buchbinder, Barry (NIH/NIAID) [E]]

Today, a script that I use every day stated giving me the following
error message.  (I grant that it might have started earlier and I
didn't notice.)  Note that although it gave the error message, the
script seems to still have worked.

./lddir: line 77: [: too many arguments

Line 77 was as follows.  I'm testing whether $1 is "clip".

if [ x$1 = xclip ]

I fixed it with this.

if [ "x$1" = xclip ]

32-bit, everything was up to date.

I've solved my problem, but the change was unexpected and, for me,
inexplicable, so I thought that I'd report it.

Let me know if you want/need more information.

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Change in behavior of bash / if [

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

On 12/17/2013 08:02 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> Today, a script that I use every day stated giving me the following
> error message.  (I grant that it might have started earlier and I
> didn't notice.)  Note that although it gave the error message, the
> script seems to still have worked.
> 
> ./lddir: line 77: [: too many arguments
> 
> Line 77 was as follows.  I'm testing whether $1 is "clip".
> 
> if [ x$1 = xclip ]

What was $1 at the time?

> 
> I fixed it with this.
> 
> if [ "x$1" = xclip ]

Yes, this is the correct fix for the improper quotation of the earlier
example.

> 
> 32-bit, everything was up to date.
> 
> I've solved my problem, but the change was unexpected and, for me,
> inexplicable, so I thought that I'd report it.

Your quoting error would produce the same message on Linux; it is not
cygwin-specific.

> 
> Let me know if you want/need more information.

Without knowing how $1 was set, I can only guess that it contained
something with characters in $IFS and therefore the word-splitting of
the unquoted use caused too many arguments to [.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

RE: Change in behavior of bash / if [

[Buchbinder, Barry (NIH/NIAID) [E]]

Eric Blake sent the following at Tuesday, December 17, 2013 11:08 PM
>On 12/17/2013 08:02 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
>> Today, a script that I use every day stated giving me the following
>> error message.  (I grant that it might have started earlier and I
>> didn't notice.)  Note that although it gave the error message, the
>> script seems to still have worked.

In my original post, I should have reported that it is a bash script.

>> ./lddir: line 77: [: too many arguments
>>
>> Line 77 was as follows.  I'm testing whether $1 is "clip".
>>
>> if [ x$1 = xclip ]
>
>What was $1 at the time?

clip

>> I fixed it with this.
>>
>> if [ "x$1" = xclip ]
>
>Yes, this is the correct fix for the improper quotation of the earlier
>example.

But why would it need quoting unless the first argument unless the
command line is quoted and might have a space"?  It wasn't.  It was
called from a script that was being sourced by a bash interactive shell
as follows.

lddir clip

"clip is telling lddir to get its input from the clipboard instead of
the command line.  "clip" is never used with another argument.  The
calling script is being sourced because it is change the working
directory of the interactive shell.  And the path of that directory
is known to not have spaces.

>> 32-bit, everything was up to date.
>>
>> I've solved my problem, but the change was unexpected and, for me,
>> inexplicable, so I thought that I'd report it.
>
>Your quoting error would produce the same message on Linux; it is not
>cygwin-specific.
>>
>> Let me know if you want/need more information.
>
>Without knowing how $1 was set, I can only guess that it contained
>something with characters in $IFS and therefore the word-splitting of
>the unquoted use caused too many arguments to [.

For that, it would have to be called with $1 on the command line in
quotes, which it wasn't.  Something like the following.

lddir "111 one" 222 "three 333" 444

And then there's the fact that I've been using lddir with no changes
for the past year and it just started misbehaving now.

Speculation:  Since cygwin1.dll was updated last week, perhaps
something happened there.  But if no one else reports a similar
problem, it might be something peculiar to my installation and use
and not worth debugging.

Thanks for your response.

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

Re: Change in behavior of bash / if [

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

On 12/18/2013 07:18 AM, Buchbinder, Barry (NIH/NIAID) [E] wrote:

>>> if [ "x$1" = xclip ]
>>
>> Yes, this is the correct fix for the improper quotation of the earlier
>> example.
> 
> But why would it need quoting unless the first argument unless the
> command line is quoted and might have a space"?  It wasn't.  It was
> called from a script that was being sourced by a bash interactive shell
> as follows.
> 
> lddir clip

I'd need to see your entire script to know for sure.  Perhaps you are
using calls to 'set' or using shell functions, either of which modifies
$1 from the value that you passed on the command line.  But the point
remains - your improper quoting of $1 is not a cygwin-specific issue.

> Speculation:  Since cygwin1.dll was updated last week, perhaps
> something happened there.

Less likely.  But without seeing your entire script, it's hard to say.
You haven't given anyone else enough to go on.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

RE: Change in behavior of bash / if [

[Buchbinder, Barry (NIH/NIAID) [E]]

[-- Attachment #1: Type: text/plain, Size: 3123 bytes --]

To close the loop:

I thought that before hitting "Send" with my response to Eric's latest
email, I should check to see if the problem was still happening.  I
removed the quotes from around x$1 and ran it.  The scripts now works
as expected.  So whatever it was, it was temporary and can no longer be
reproduced.  Sigh.

Eric, thanks for all the time you put into addressing this issue.

Best wishes,

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

----

The following is for the archive in case this comes up again.  (Really
because I wrote it before I thought to test to see if the behavior had
fixed itself.)  I don't expect anyone to read it or do anything.

Eric Blake sent the following at Wednesday, December 18, 2013 10:28 AM
>On 12/18/2013 07:18 AM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
>>>> if [ "x$1" = xclip ]
>>>
>>> Yes, this is the correct fix for the improper quotation of the earlier
>>> example.
>>
>> But why would it need quoting unless the first argument unless the
>> command line is quoted and might have a space"?  It wasn't.  It was
>> called from a script that was being sourced by a bash interactive shell
>> as follows.
>>
>> lddir clip
>
>I'd need to see your entire script to know for sure. Perhaps you are
>using calls to 'set' or using shell functions, either of which modifies
>$1 from the value that you passed on the command line. But the point
>remains - your improper quoting of $1 is not a cygwin-specific issue.
>> Speculation:  Since cygwin1.dll was updated last week, perhaps
>> something happened there.
>
>Less likely. But without seeing your entire script, it's hard to say.
>You haven't given anyone else enough to go on.

Here are the scripts without the quotes.  Both are kept in /BW, which
is NOT in the path.

ldc is accessed as an alias, set in ~/.bashrc.

/BW> alias ldc
alias ldc='. /BW/ldc'

Background:

lddir was written first.  It was used to load Windows Explorer in a
particular directory that was based on a string provided as an argument.
(lddir was written to avoid a lot of effort navigating a directory tree
in Explorer.)

ldc was written second.  It takes a string from the Windows clipboard,
finds a substring of the format that lddir is looking for, gets a posix
path from lddir based on the substring, changes to the directory of that
path, feeds the windows version of that path to the clipboard, and does
a bunch of other stuff.  (ldc was designed so I could easily get a
string from an email and generate a path so I could easily get to the
folder where I needed to save it's attachments.  Additionally, it move
my shell to that directory so I can use cygwin tools on it.  Originally
it just did the clipboard -> path -> clipboard + cd and with time the
"bunch of other stuff" was added.  I should probably combine them.)

Anyway, thanks for taking interest in this.  As I said, I added the
quotes and it works so I don't really need this fixed.

Best wishes,

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

[-- Attachment #2: ldc --]
[-- Type: application/octet-stream, Size: 3444 bytes --]

[-- Attachment #3: lddir --]
[-- Type: application/octet-stream, Size: 2050 bytes --]

[-- Attachment #4: Type: text/plain, Size: 218 bytes --]

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple