On 2024-04-15, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> Bash has an option that tells it to (attempt to) restrict itself to
> POSIX semantics:

No, it does not:

> Starting Bash with the '--posix' command-line option or executing
> 'set -o posix' while Bash is running will cause Bash to conform more
> closely to the POSIX standard by changing the behavior to match that
> specified by POSIX in areas where the Bash default differs.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This only tweaks bash's behavior where it otherwise differs from
POSIX. It does not disable the myriad extensions.

There is a tool ShellCheck that among other things can be used to
warn about unportable code in shell scripts.
https://www.shellcheck.net/

I haven't used it myself yet. It is written in Haskell, so it
suffers itself from portability concerns.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

Christian Weisgerber <naddy@mips.inka.de> writes:
> On 2024-04-15, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Bash has an option that tells it to (attempt to) restrict itself to
>> POSIX semantics:
>
> No, it does not:
>
>> Starting Bash with the '--posix' command-line option or executing
>> 'set -o posix' while Bash is running will cause Bash to conform more
>> closely to the POSIX standard by changing the behavior to match that
>> specified by POSIX in areas where the Bash default differs.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> This only tweaks bash's behavior where it otherwise differs from
> POSIX. It does not disable the myriad extensions.

I stand corrected.

> There is a tool ShellCheck that among other things can be used to
> warn about unportable code in shell scripts.
> https://www.shellcheck.net/
>
> I haven't used it myself yet. It is written in Haskell, so it
> suffers itself from portability concerns.

There's also a "shellcheck" application, installable as a package on
Ubuntu and presumably many other systems. I use it regularly, almost
always on scripts with "#!/bin/bash" so it doesn't check POSIX rules.
But when invoked on a script with "#!/bin/sh" or with "--shell=sh" it
claims to warn about POSIX portability issues.

https://github.com/koalaman/shellcheck

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

In article <87y19dqgsh.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>Christian Weisgerber <naddy@mips.inka.de> writes:
>> On 2024-04-15, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> Bash has an option that tells it to (attempt to) restrict itself to
>>> POSIX semantics:
>>
>> No, it does not:
>>
>>> Starting Bash with the '--posix' command-line option or executing
>>> 'set -o posix' while Bash is running will cause Bash to conform more
>>> closely to the POSIX standard by changing the behavior to match that
>>> specified by POSIX in areas where the Bash default differs.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> This only tweaks bash's behavior where it otherwise differs from
>> POSIX. It does not disable the myriad extensions.
>
>I stand corrected.

ISTR (which is to say, I can't prove it or point to an example at the
moment), that there were some systems under some circumstances where if
bash was copied/linked as "sh" (and then run as "sh" instead of "bash"),
then it did indeed behave like a plain "POSIX" shell (i.e., extensions were
disabled).

It is to be noted that bash is an evolving (i.e., changing) program and
there is no written "standard" for it - like Perl, it is just whatever its
current maintainers makes it out to be at any particular moment. This
makes it hard to make the kind of hard-and-fast statements about it that
people in newsgroups like this one like so much to do.

--
Elect a clown, expect a circus.

On 2024-04-16, Christian Weisgerber <naddy@mips.inka.de> wrote:
> On 2024-04-15, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> Bash has an option that tells it to (attempt to) restrict itself to
>> POSIX semantics:
>
> No, it does not:
>
>> Starting Bash with the '--posix' command-line option or executing
>> 'set -o posix' while Bash is running will cause Bash to conform more
>> closely to the POSIX standard by changing the behavior to match that
>> specified by POSIX in areas where the Bash default differs.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> This only tweaks bash's behavior where it otherwise differs from
> POSIX. It does not disable the myriad extensions.

"set -o posix" disabling conforming extensions would be a GCC-grade
stupidity.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-04-16, Kenny McCormack <gazelle@shell.xmission.com> wrote:

> ISTR (which is to say, I can't prove it or point to an example at the
> moment), that there were some systems under some circumstances where if
> bash was copied/linked as "sh" (and then run as "sh" instead of "bash"),
> then it did indeed behave like a plain "POSIX" shell (i.e., extensions were
> disabled).

From the man page:
If bash is invoked with the name sh, it tries to mimic the startup
behavior of historical versions of sh as closely as possible, while
conforming to the POSIX standard as well. [...]
When invoked as sh, bash enters posix mode after the startup files are
read.

However, it is possible to disable a lot of features at build time.
In particular, configuring bash with --enable-minimal-config produces
a much reduced feature set:

dnl a minimal configuration turns everything off, but features can be
dnl added individually
if test $opt_minimal_config = yes; then
opt_job_control=no opt_alias=no opt_readline=no
opt_history=no opt_bang_history=no opt_dirstack=no
opt_restricted=no opt_process_subst=no opt_prompt_decoding=no
opt_select=no opt_help=no opt_array_variables=no opt_dparen_arith=no
opt_brace_expansion=no opt_disabled_builtins=no opt_command_timing=no
opt_extended_glob=no opt_cond_command=no opt_arith_for_command=no
opt_net_redirs=no opt_progcomp=no opt_separate_help=no
opt_multibyte=yes opt_cond_regexp=no opt_coproc=no
opt_casemod_attrs=no opt_casemod_expansions=no opt_extglob_default=no
opt_translatable_strings=no
opt_globascii_default=yes
fi

--
Christian "naddy" Weisgerber naddy@mips.inka.de

Kaz Kylheku <643-408-1753@kylheku.com> writes:
> On 2024-04-16, Christian Weisgerber <naddy@mips.inka.de> wrote:
>> On 2024-04-15, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>> Bash has an option that tells it to (attempt to) restrict itself to
>>> POSIX semantics:
>>
>> No, it does not:
>>
>>> Starting Bash with the '--posix' command-line option or executing
>>> 'set -o posix' while Bash is running will cause Bash to conform more
>>> closely to the POSIX standard by changing the behavior to match that
>>> specified by POSIX in areas where the Bash default differs.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> This only tweaks bash's behavior where it otherwise differs from
>> POSIX. It does not disable the myriad extensions.
>
> "set -o posix" disabling conforming extensions would be a GCC-grade
> stupidity.

An option to disable conforming extensions, whether it's spelled "set -o
posix" or in some other way, could be very useful for people who would
like to write scripts that don't (perhaps unintentionally) depend on any
extensions.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Tue, 16 Apr 2024 11:11:16 -0000 (UTC), Christian Weisgerber wrote:

> On 2024-04-15, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
> There is a tool ...

Or just use a basic POSIX shell. Such things exist, you know.

> ... ShellCheck that among other things can be used to warn
> about unportable code in shell scripts. https://www.shellcheck.net/

I don’t see any mention of “unportability”, only about “bugs”.

Just for fun, I tried this:

#!/bin/bash

collect_expand()
{
local -n arr="$2"
arr=()
coproc expander { find . -maxdepth 1 -name "$1" -print0; }
# must ensure while-loop runs in this process
while read -u ${expander[0]} -rd '' line; do
arr[${#arr[*]}]="$line"
done
wait $expander_PID
} # collect_expand

#+
# Mainline
#-

test_filenames=('file 1.dat' $'file number\n2.dat' $'file\t3 dat')
# test multiple spaces in a row and newlines, among any other odd
# things you can think of!

tmpdir=$(mktemp -d -p '' collect-work.XXXXXXXXXX)
echo "tmpdir =" $(printf %q "$tmpdir")

cd "$tmpdir"
for f in "${test_filenames[@]}"; do
echo "create" $(printf %q "$f")
touch "$f"
done

collect_expand '*dat' found_filenames
for f in "${found_filenames[@]}"; do
echo "found" $(printf %q "$f")
done

cd
rm -rfv "$tmpdir"

and it came back with

Line 9:
while read -u ${expander[0]} -rd '' line; do
^-- SC2086 (info): Double quote to prevent globbing and word splitting.

Did you mean: (apply this, apply all SC2086)
while read -u "${expander[0]}" -rd '' line; do

Line 12:
wait $expander_PID
^-- SC2154 (warning): expander_PID is referenced but not assigned.
^-- SC2086 (info): Double quote to prevent globbing and word splitting.

Did you mean: (apply this, apply all SC2086)
wait "$expander_PID"

Line 24:
echo "tmpdir =" $(printf %q "$tmpdir")
^-- SC2046 (warning): Quote this to prevent word splitting.

Line 26:
cd "$tmpdir"
^-- SC2164 (warning): Use 'cd ... || exit' or 'cd ... || return' in case cd fails.

Did you mean: (apply this, apply all SC2164)
cd "$tmpdir" || exit

Line 28:
echo "create" $(printf %q "$f")
^-- SC2046 (warning): Quote this to prevent word splitting.

Line 33:
for f in "${found_filenames[@]}"; do
^-- SC2154 (warning): found_filenames is referenced but not assigned.

Line 34:
echo "found" $(printf %q "$f")
^-- SC2046 (warning): Quote this to prevent word splitting.

Line 37:
cd
^-- SC2164 (warning): Use 'cd ... || exit' or 'cd ... || return' in case cd fails.

Did you mean: (apply this, apply all SC2164)
cd || exit

I would have to count every single one of those messages as spurious.

In article <uvn6ga$17j5g$3@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Tue, 16 Apr 2024 11:11:16 -0000 (UTC), Christian Weisgerber wrote:
>
>> On 2024-04-15, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>> There is a tool ...
>
>Or just use a basic POSIX shell. Such things exist, you know.
>
>> ... ShellCheck that among other things can be used to warn
>> about unportable code in shell scripts. https://www.shellcheck.net/
>
>I dont see any mention of unportability, only about bugs.

ShellCheck reads the #! line and figures out which flavor of shell you are
using, but this can be overridden by a command line switch. So, presumably,
you could tell it to parse your batch script as if it were plain old
"POSIX" (i.e., crippled) sh.

>Just for fun, I tried this:
....
>I would have to count every single one of those messages as spurious.

Yes, ShellCheck complains about a lot of things, and most of its complaints
can and should be ignored. I still find it interesting and useful, but you
have to take (most of) what it says with a (big) grain of salt.

--
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/WeekendAwayFromHome

On 2024-04-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

>> ... ShellCheck that among other things can be used to warn
>> about unportable code in shell scripts. https://www.shellcheck.net/
>
> I don’t see any mention of “unportability”, only about “bugs”.

https://www.shellcheck.net/wiki/
The long list of items also has just short of sixty about things
that are undefined in POSIX sh.

--
Christian "naddy" Weisgerber naddy@mips.inka.de