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

Groups > comp.unix.shell > #25055 > unrolled thread

Which shell and how to get started handling arguments

Back to article view | Back to comp.unix.shell

Contents

  Which shell and how to get started handling arguments James Harris <james.harris.1@gmail.com> - 2024-04-15 13:22 +0100
    Re: Which shell and how to get started handling arguments Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-04-15 16:03 +0200
      Re: Which shell and how to get started handling arguments Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-04-15 16:34 +0200
    Re: Which shell and how to get started handling arguments Christian Weisgerber <naddy@mips.inka.de> - 2024-04-15 13:35 +0000
      Re: Which shell and how to get started handling arguments Helmut Waitzmann <nn.throttle@xoxy.net> - 2024-04-15 23:03 +0200
        Re: Which shell and how to get started handling arguments Kaz Kylheku <643-408-1753@kylheku.com> - 2024-04-16 01:14 +0000
          Re: Which shell and how to get started handling arguments Helmut Waitzmann <nn.throttle@xoxy.net> - 2024-04-16 22:23 +0200
    Re: Which shell and how to get started handling arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-04-15 15:45 +0100
    Re: Which shell and how to get started handling arguments Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-04-15 15:06 +0000
      Re: Which shell and how to get started handling arguments Christian Weisgerber <naddy@mips.inka.de> - 2024-04-15 15:36 +0000
        Re: Which shell and how to get started handling arguments gazelle@shell.xmission.com (Kenny McCormack) - 2024-04-15 17:38 +0000
          Re: Which shell and how to get started handling arguments Kaz Kylheku <643-408-1753@kylheku.com> - 2024-04-15 17:57 +0000
        Re: Which shell and how to get started handling arguments Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-04-15 20:37 +0000
      Re: Which shell and how to get started handling arguments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-04-15 14:31 -0700
        Re: Which shell and how to get started handling arguments Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-04-16 10:19 +0200
        Re: Which shell and how to get started handling arguments Christian Weisgerber <naddy@mips.inka.de> - 2024-04-16 11:11 +0000
          Re: Which shell and how to get started handling arguments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-04-16 11:54 -0700
            Re: Which shell and how to get started handling arguments gazelle@shell.xmission.com (Kenny McCormack) - 2024-04-16 19:59 +0000
              Re: Which shell and how to get started handling arguments Christian Weisgerber <naddy@mips.inka.de> - 2024-04-16 21:57 +0000
          Re: Which shell and how to get started handling arguments Kaz Kylheku <643-408-1753@kylheku.com> - 2024-04-16 20:45 +0000
            Re: Which shell and how to get started handling arguments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-04-16 16:38 -0700
          Re: Which shell and how to get started handling arguments Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-04-17 00:52 +0000
            Re: Which shell and how to get started handling arguments gazelle@shell.xmission.com (Kenny McCormack) - 2024-04-17 09:02 +0000
            Re: Which shell and how to get started handling arguments Christian Weisgerber <naddy@mips.inka.de> - 2024-04-17 14:23 +0000
    Re: Which shell and how to get started handling arguments Helmut Waitzmann <nn.throttle@xoxy.net> - 2024-04-15 23:49 +0200
    Re: Which shell and how to get started handling arguments Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-04-15 22:20 +0000

Page 2 of 2 — ← Prev page 1 [2]

#25108

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

[toc] | [prev] | [next] | [standalone]

#25109

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.

[toc] | [prev] | [next] | [standalone]

#25117

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

[toc] | [prev] | [next] | [standalone]

#25124

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

[toc] | [prev] | [next] | [standalone]

#25069

 James Harris <james.harris.1@gmail.com>:

> I read up on getopts but from tests it seems to require that 
> switches precede arguments 
>

 Yes, that's true. 


> rather than allowing them to be specified after, so that doesn't 
> seem very good, either. 
>

 The problem with specifying options after non‐option arguments is 
 that non‐option arguments may take any form:  They even may start 
 with an "-", that is, look like options even when they aren't 
 meant to be used as options. 


 So, if you have some command "some_command" with one non‐option 
 argument "a" followed by an option "-b" 


    $ some_command -a -b


 and parse the arguments from left to right then there is no way 
 for "some_command" to investigate that "-a" is to be taken as a 
 non‐option argument while "-b" is to be taken as an option. 


 Whereas, when "some_command" expects options before any 
 non‐option argument and recognizes the end‐of‐options marker 
 ("--") then there is no ambiguity: 


   $ some_command -b -- -a


 "-b" is an option, while "-a" (because the series of options is 
 terminated by the end‐of‐options marker) is the (first) 
 non‐option argument "-a". 


 That's the way how the POSIX‐shell builtin "getopts" works. 

[toc] | [prev] | [next] | [standalone]

#25071

On Mon, 15 Apr 2024 13:22:14 +0100, James Harris wrote:

> I am thinking to write in /the language of/ the Bourne shell, if
> feasible, so that it could be run by either the Bourne shell or Bash,
> etc? (Ideally, the shebang line would be #!/bin/sh.)

There is such a thing as a standardized “POSIX shell”. On Debian, for 
example, /bin/sh will launch Dash, which is a minimal POSIX-compliant 
shell.

It’s certainly a safe, boring choice. ;)

> Or is Bash now so universal that there's no point any longer in writing
> for anything else?

This is where we get into “Unix®” the trade mark, versus “Unix” as an 
informal description of a collection of traditional OS behaviour.

I say this because the only currently “Unix®” trade mark licensee still 
seeing any significant use is Apple’s macOS, and that does not offer 
Bash--at least, not any reasonably recent version. This is for ideological 
reasons or something.

So if you are targeting “Unix” in the latter sense, then Bash is quite 
widespread, yes.

> I read up on getopts but from tests it seems to require that switches
> precede arguments rather than allowing them to be specified after, so
> that doesn't seem very good, either.

One reason for that convention is that it is possible for file/directory 
names to begin with “-”. To minimize the confusion this causes, there is a 
an additional common convention among command-line tools that a plain “--” 
option means “don’t look for any more options after this”. That is to say, 
treat the remaining items as file names (or whatever else the program does 
with them), even if they begin with “-”.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.unix.shell

csiph-web