Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #14813 > unrolled thread

Re: built-in '[' and '/usr/bin/[' yield different results

Started byGreg Wooledge <wooledg@eeg.ccf.org>
First post2018-11-13 12:54 -0500
Last post2018-11-13 12:54 -0500
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: built-in '[' and '/usr/bin/[' yield different results Greg Wooledge <wooledg@eeg.ccf.org> - 2018-11-13 12:54 -0500

#14813 — Re: built-in '[' and '/usr/bin/[' yield different results

FromGreg Wooledge <wooledg@eeg.ccf.org>
Date2018-11-13 12:54 -0500
SubjectRe: built-in '[' and '/usr/bin/[' yield different results
Message-ID<mailman.3985.1542131699.1284.bug-bash@gnu.org>
On Tue, Nov 13, 2018 at 05:29:42PM +0100, Service wrote:
> Repeat-By:
>     Under Windows 10, WSL.

Then why did you send this to a debian.org address?

>     Start "bash", terminal with shell pops up.

>     2. This does not work:
> 
>     # Put the above commands into a script, say check.sh
>     # Run with: /bin/sh < check.sh
>     # Or      : /bin/sh ./check.sh

In both of these cases, you're explicitly calling /bin/sh rather than
bash.  So you are not using bash's builtin [.  You are using WSL's sh's
builtin [ command.  You might start by identifying which shell WSL uses
as its sh.

>     # Or      : /usr/bin/env ./check.sh

In this case, it would use the shebang line of check.sh to decide which
shell to run.  However, I suspect you did not include a shebang line at
all.  In that case, /usr/bin/env will decide how to handle the exec
format error.  It might decide to spawn sh for you, in which case this
would explain why the result matches the first two results.

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web