Command working at the CLI but not in a acript

[Harold Johanssen]

I am using the following at the bash command line:

diff <(/binls /tmp/d1) <(/bin/ls /tmp/d2)

where d1 and d2 are two directories. The line above will feed the
contents of those directories to diff, as though they were the contents
of two separate files. diff will then proceed to determine their
differences, sending those differences out to the standard output.

This works correctly when I type it at the command line. However,
when I enter exactly the same line in a shell script myscript, when
executing myscript I get the following error;

./myscript: line 3: syntax error near unexpected token `('
./myscript: line 3: 'diff <(/bin/ls /tmp/d1) <(/bin/ls /tmp/d2)'

Why does this not work in the scrip? Can it be made to work?

[Harold Johanssen]

Answering my own question which, as is eerily often the case, I
figured out shortly after posting it here:

Process substitution is no a POSIX compliant feature. In my
script, one can get around this by preceding the 'diff' line above with
the following line:

set +o posix

I still do not understand why I have to do this in the script but
not in my command line.

[Ben Bacarisse]

Harold Johanssen <noe...@please.net> writes:

> On Sun, 13 Aug 2017 00:08:11 +0000, Harold Johanssen wrote:
>
>> I am using the following at the bash command line:
>>
>> diff <(/binls /tmp/d1) <(/bin/ls /tmp/d2)

<snip>

>> Why does this not work in the scrip?
>

> Answering my own question which, as is eerily often the case, I
> figured out shortly after posting it here:
>
> Process substitution is no a POSIX compliant feature. In my
> script, one can get around this by preceding the 'diff' line above with
> the following line:
>
> set +o posix
>
> I still do not understand why I have to do this in the script but
> not in my command line.

It's going to come down to what shell (and in what mode) is executing
the script. If the script has no initial #! line, I think /bin/sh is
used and that's often ether a POSIX shell or something like bash in
POSIX mode. What is the full text of your script?

--
Ben.

[Cecil Westerhof]

Harold Johanssen <noe...@please.net> writes:

> On Sun, 13 Aug 2017 00:08:11 +0000, Harold Johanssen wrote:
> Answering my own question which, as is eerily often the case, I
> figured out shortly after posting it here:

Join the club. I have the same ‘problem’. A newsgroup can function as
a rubber duck. :-D

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[Harold Johanssen]

Very simple:

#! /bin/sh

[Teemu Likonen]

Harold Johanssen [2017-08-13 13:49:09Z] wrote:

>> Harold Johanssen <noe...@please.net> writes:
>>> I still do not understand why I have to do this in the script but
>>> not in my command line.

> #! /bin/sh
>
> diff <(/bin/ls /tmp/d1) <(/bin/ls /tmp/d2)

The answer is simple: if you use Bash's features (like <(...)) run the
script with Bash:

#!/bin/bash

diff <(/bin/ls /tmp/d1) <(/bin/ls /tmp/d2)

--
/// Teemu Likonen - .-.. <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[Janis Papanagnou]

So you are not implicitly but explicitly using /bin/sh which is behaving
like a POSIX shell where process substitution doesn't work. Note that your
workaround (to set the posix option) is strictly speaking also a non-POSIX
option (one that's not defined by POSIX). So if you want to use process
substitution it's best to define an interpreter that supports this feature;
#!/bin/ksh, #!/bin/zsh, or, #!/bin/bash, to name a few prominent ones.

Janis

[Jens Stuckelberger]

I tried that; it did not work. Anyway, in my Linux distribution
(Slackware 14.2) /bin/sh is a symbolic link from /bin/bash.

[Janis Papanagnou]

Shells may show different behaviour depending on the name it is called as;
the OP observed that difference (as did another poster recently with cron).

I don't know details of your distribution. Reasons why those interpreters
don't work in your case could for example be that those shells may be in a
different directory (/usr/bin/*sh), or that you have old software or shell
clones instead of the original ones. Inspect where the shell paths are,
and check that you have a modern shell that supports process substitution.
Or maybe you haven't made your script executable. Try running your script
explicitly with the correct interpreter, bash myscript, instead of myscript.

Janis

[Harold Johanssen]

You are on to something there - when I invoke it as

bash ./myscript

it does work, without having to add set +o posix. Thanks,

[Chris Elvidge]

From the bash man page:

"If bash is invoked with the name sh, it tries to mimic the historical
versions of sh as closely as possible, while conforming to the POSIX
standard as well."

I.e. Just because sh is a symlink to bash, you don't get full bash
functionality from /bin/sh


--

Chris Elvidge, England

[Kenny McCormack]

In article <omrqs7$shi$1...@dont-email.me>,
Chris Elvidge <ch...@mshome.net> wrote:
...

> From the bash man page:
>
>"If bash is invoked with the name sh, it tries to mimic the historical
>versions of sh as closely as possible, while conforming to the POSIX
>standard as well."
>
>I.e. Just because sh is a symlink to bash, you don't get full bash
>functionality from /bin/sh

However, note that this isn't guaranteed. You can test with the command:

$ /bin/sh -c 'echo $BASH_VERSION'

On at least one system with which I am familiar, this displays a non-empty
string. This fact has implications for that system...

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/RightWingMedia

[Kaz Kylheku]

On 2017-08-13, Harold Johanssen <noe...@please.net> wrote:
> set +o posix
>
> I still do not understand why I have to do this in the script but
> not in my command line.

I'm going to go on two long, thin limbs here:

1. It's a #! script, and the #! line is #!/bin/sh not #!/bin/bash

2. It's just an executable text file with no #! line.

[Barry Margolin]

In article <omru8p$1cq$1...@news.xmission.com>,

gaz...@shell.xmission.com (Kenny McCormack) wrote:

> In article <omrqs7$shi$1...@dont-email.me>,
> Chris Elvidge <ch...@mshome.net> wrote:
> ...
> > From the bash man page:
> >
> >"If bash is invoked with the name sh, it tries to mimic the historical
> >versions of sh as closely as possible, while conforming to the POSIX
> >standard as well."
> >
> >I.e. Just because sh is a symlink to bash, you don't get full bash
> >functionality from /bin/sh
>
> However, note that this isn't guaranteed. You can test with the command:
>
> $ /bin/sh -c 'echo $BASH_VERSION'
>
> On at least one system with which I am familiar, this displays a non-empty
> string. This fact has implications for that system...

What does that prove? Is there something in POSIX that prohibits setting
that variable?

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***