On 4/27/23 06:34, Janis Papanagnou wrote:
> This is how Unix shells work. It may make sense to take an hour or
> two to read about "command processing" in shells; the command line
> parsing process has a lot of steps that you shall be aware of if you
> intend to program in shell.

I've taken several classes in shell scriupting over the last 30 years,
and then I see something like this and it reminds me that I seem to
learn nothing.

Do you have a link to a resource?

On 4/27/23 12:46, Felix Palmen wrote:
> For a script, the script is (logically) the executable, the shell just
> acts as an interpreter and will set $0 accordingly.

Right, but I would think though, that once #!/bin/bash is reached, that
a new shell executatible in formed in ram or on the stack with a new PID
and why should it be aware of what happened previously when the $0 is
expanded.

Do you see my point of confusion?

Reuvain

* Popping Mad <rainbow@colition.gov>:
> Right, but I would think though, that once #!/bin/bash is reached, that
> a new shell executatible in formed in ram or on the stack with a new PID
> and why should it be aware of what happened previously when the $0 is
> expanded.

The shebang tells the OS which binary to run as the interpreter (feeding
the script and all its arguments to it). But keep in mind that argv[]
contains the WHOLE command line typed, so argv[0] is the command's name.

The exec() family of functions allows to specify argv[] and the actual
executable separately, and this is what happens when executing a script
that has a shebang. The binary named in the shebang is executed, but it
gets fed the original commandline in argv[], including the original
argv[0]. As a consequence, you will e.g. also see the script name in
'ps' output (and not the shell that's executing it).

Now, if you don't have a shebang but execute some script calling the
shell yourself, the shell will still know it's running as an interpreter
and therefore set $0 to argv[1] and so on.

--
Dipl.-Inform. Felix Palmen <felix@palmen-it.de> ,.//..........
{web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de
{pgp public key} http://palmen-it.de/pub.txt // """""""""""
{pgp fingerprint} 6936 13D5 5BBF 4837 B212 3ACC 54AD E006 9879 F231

On Thu, 27 Apr 2023 12:53:46 -0400, Popping Mad <rainbow@colition.gov> wrote:
> Right, but I would think though, that once #!/bin/bash is reached, that
> a new shell executatible in formed in ram or on the stack with a new PID
> and why should it be aware of what happened previously when the $0 is
> expanded.
> Do you see my point of confusion?

Also note that the shebang is only used if the script is executed as a
command.

[dave@x3 bin]$ echo $0
/bin/bash

I'm running konsole under kde and as shown above, it's set to run bash.

[dave@x3 bin]$ cat echodollarzero
#!/bin/bash
echo $0

~/bin is in my path and ~/bin/echodollarzero is marked executable.

[dave@x3 bin]$ echodollarzero
/home/dave/bin/echodollarzero
[dave@x3 bin]$ ./echodollarzero
../echodollarzero

In both of the above, execve (see "man execve") uses the shebang to decide
which interpreter to use, and passes it the command line as entered as the
first parameter ($0).

[dave@x3 bin]$ ksh -c echodollarzero
/home/dave/bin/echodollarzero
[dave@x3 bin]$ strace -f ksh -c echodollarzero 2>&1|grep execve
execve("/usr/bin/ksh", ["ksh", "-c", "echodollarzero"], 0x7ffe2b383c28 /* 99 vars */) = 0
[pid 301725] execve("/home/dave/bin/echodollarzero", ["echodollarzero"], 0xce4e48 /* 103 vars */) = 0

In the above, the shebang is ignored. It's processed by ksh which sets $0
to the full path and filename of the script rather then just the command as
entered.

Regards, Dave Hodgins

On 27.04.2023 18:49, Popping Mad wrote:
> On 4/27/23 06:34, Janis Papanagnou wrote:
>> This is how Unix shells work. It may make sense to take an hour or
>> two to read about "command processing" in shells; the command line
>> parsing process has a lot of steps that you shall be aware of if you
>> intend to program in shell.
>
> I've taken several classes in shell scriupting over the last 30 years,
> and then I see something like this and it reminds me that I seem to
> learn nothing.
>
> Do you have a link to a resource?

For links you have to use google and the mentioned keywords. Myself I
learned these things from books, e.g. Bolsky, Korn "The new Kornshell",
(1995, Prentice Hall); see chapter 11 ("command processing"). But you
probably will find also online resources if you search for "shells",
"command processing", and the 10+ steps taken, e.g. "tilde expansion",
"command substitution", "arithmetic expansion", "field splitting",
"pathname expansion", "path search", etc. (I'm not sure whether you
find these details also in the POSIX specification; might at least be
worth a try.[*]) A quick look into the bash or ksh man-pages seems
to provide also some information, but it's not well-structured and
provides no top-down overview, it seems. Below I appended from an old
ksh course - but it's written in German - the processing steps listed,
from these you may look up the details of the single steps in the
shell man pages.

Janis

[*]
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html

===

Die Zeile wird in Token getrennt.

Es wird nach den erlaubten Schlüsselwörtern gesucht. Im Falle einer
zusammengesetzten Anweisung (z.B. while, for, if, ...) wird interne
Verwaltungs-Information aufgebaut und rekursiv für die eingebetteten
Anweisungen erneut beim ersten Schritt begonnen.

Unerwartete Schlüsselwörte (z.B. done ohne do, fi ohne if) führen hier
zu einer Fehlermeldung mit Terminierung.

Suche nach angewendeten Aliasen. Im Falle des Einsatzes eines Alias wird
dieser expandiert, und es wird mit dem ersten Schritt weitergearbeitet.

Tilde-Expansion wird durchgeführt. Z.B. wird ~user durch /home/user ersetzt.

Variablen werden expandiert.

Sub-Shell Kommandos der Art $(command) werden durchgeführt.

Arithmetische Ausdrücke $((expression)) werden ausgewertet.

Die Ergebnisse der Expansion der Schritte 5, 6 und 7 werden noch mit
einem Delimiter (Variable IFS) in einzelne Wörter getrennt.

Dateinamen und Regular Expressions werden expandiert. Hier werden z.B.
*, ?, [], *() expandiert.

Das Kommando wird in den möglichen Built-In's, in den definierten
Funktionen und als ausführbares Programm im definierten Pfad gesucht.

Zu Abschluss wird die Ein-/Ausgabe umgeleitet und das Kommando ausgeführt.

===

Popping Mad <rainbow@colition.gov> writes:
> On 4/27/23 12:46, Felix Palmen wrote:
>> For a script, the script is (logically) the executable, the shell just
>> acts as an interpreter and will set $0 accordingly.
>
> Right, but I would think though, that once #!/bin/bash is reached, that
> a new shell executatible in formed in ram or on the stack with a new PID
> and why should it be aware of what happened previously when the $0 is
> expanded.
>
> Do you see my point of confusion?

Not a new shell executable; the executable is the binary file
"/bin/bash", or whatever. It's a new shell *process*.

It would probably be easier if it consistently expanded to the path
of the shell executable, but the shell process knows the name of
the script it's executing (if any), and that information is much
more useful. In an interactive shell process, there is no script,
so it falls back to the name of the shell. $0 isn't all that useful
in an interactive context. The behavior is specified by POSIX.

Here's the relevant wording from the bash manual:

'0'
($0) Expands to the name of the shell or shell script. This is set
at shell initialization. If Bash is invoked with a file of
commands (*note Shell Scripts::), '$0' is set to the name of that
file. If Bash is started with the '-c' option (*note Invoking
Bash::), then '$0' is set to the first argument after the string to
be executed, if one is present. Otherwise, it is set to the
filename used to invoke Bash, as given by argument zero.

https://www.gnu.org/software/bash/manual/bash.html

or type "info bash" for an interactive view (type 'h' for help if you're
not familiar with the "info" viewer).

It's also described in the POSIX sh manual under "Special Parameters".
(It's difficult to search for because it's shown as "0", not "$0".)

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_02

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

felix@palmen-it.de (Felix Palmen):
> * Popping Mad <rainbow@colition.gov>:

> The shebang tells the OS which binary to run as the interpreter
> (feeding the script and all its arguments to it). But keep in
> mind that argv[] contains the WHOLE command line typed, so
> argv[0] is the command's name.

To be more precise:  It's not the command line that is passed to
the invoked binary (in this case: the invoked shell running the
script).  It's the argument vector ("argv", see the "execve(2)"
manual page) of the simple command that is passed to the invoked
binary.

The argument vector, though, is constructed out of the command
line by the invoking shell which reads and parses the command
line as typed by the user.  That's why the "$0" is not seen by
the invoked binary:  The invoking shell, interpreting the "$0",
has already replaced it by its own invocation name.

> The exec() family of functions allows to specify argv[] and the actual
> executable separately, and this is what happens when executing a script
> that has a shebang. The binary named in the shebang is executed, but it
> gets fed the original commandline in argv[], including the original
> argv[0].

At least, my Debian 10 Linux apparently doesn't follow that part
of the last sentence that begins with "but it gets fed":  If I
write the shell script named "show_args", as follows:

#!/bin/sh
bash_printf()
{
bash -c -- 'printf "$@"' bash "$@"
}
ps -o ppid -o sid -o pgid -o pid -o stat \
-o args=argv -p "$$"
bash_printf '%s\n' '"$0" and "$@" (shell-quoted):'
bash_printf '%q\n' "$0" "$@"

… make it readable and executable and invoke it:

./show_args 'Hello,' 'world!'

> As a consequence, you will e.g. also see the script name in 'ps'
> output (and not the shell that's executing it).
>

I get the following output:

PPID SID PGID PID STAT argv
10075 10075 11141 11141 S+ /bin/sh ./show_args Hello, world!
"$0" and "$@" (shell-quoted):
./show_args
Hello\,
world\!

I get essentially the same output, if I invoke it by

sh ./show_args 'Hello,' 'world!'

PPID SID PGID PID STAT argv
10075 10075 11230 11230 S+ sh ./show_args Hello, world!
"$0" and "$@" (shell-quoted):
./show_args
Hello\,
world\!

On Thu, 27 Apr 2023 08:33:19 -0000 (UTC), Spiros Bousbouras wrote:

> On Thu, 27 Apr 2023 00:55:53 -0400 Popping Mad <rainbow@colition.gov>
> wrote:
>> On 4/26/23 13:14, Felix Palmen wrote:
>> > And then, we should finally see how $0 would be utterly pointless if
>> > *not* expanded by the shell ;)
>>
>> If it is always exanded by the shell prior to execution, it is then
>> always the name of the shell being invoked.. Does tht also not seem to
>> be pointless.
>
> It isn't always the name of the shell. Say I have a file named
> my-beautiful-shell-script which contains only 1 line :
> echo $0
>
> .If I do bash my-beautiful-shell-script I see
> my-beautiful-shell-script
>
> If I make my-beautiful-shell-script have 2 lines :
> #!/bin/bash echo $0
>
> and make it executable and execute it with ./my-beautiful-shell-script
> ,
> I see ./my-beautiful-shell-script

I recently had use for $0. But besides that, I have a
few other things going on, and it's a darned useful
script (to me, at least) but I'm also trying to have it
do some crafty stuff with the process group.

I'm relying on "kill -1 0", which if I'm not mistaken, is the
way to kill off the entire pg.

Also, this only works with the older xdaliclock that accepts
command-line options -- the new (gnome) one doesn't seem to support
it.

BTW, hat tip to jwz for an amazing clock. :) I use it with
a green background to snarfle it into an obs scene for streaming
on youtube.

--%< cut here ---
#!/bin/bash
# # wrapper around xdaliclock to use the countdown timer
# # Fri Apr 14 06:40:29 PM PDT 2023 <vallor@vallor.earth>
#

#set -x

export ME=$0

ME=${ME##*/}
ME=${ME%.*}

echo $ME

export COUNT=${1:-600} # 10 minute default

if [ "$COUNT" == "" ]
then
echo Usage: $0 seconds 1>&2
exit 1
fi

export TARGET=$[ $EPOCHSECONDS + $COUNT ]
TARGET="-countdown $TARGET"

case "$ME" in

"dali_game_clock")
export TITLE="-title $ME"
export BG='-bg #00ff00'
export CYCLE='-cycle'
export FONT='-builtin2'
export TZ=UTC
export COUNT=$[ 100 * 86400 ] # for the sleep timeout
export TARGET="-24" # 24-hour clock
;;
"dali_timer")
export TITLE="-title $ME"
export BG='-bg #00ff00'
export CYCLE='-nocycle'
export FONT='-builtin3'
;;

"dali_cycle_timer")
export TITLE="-title $ME"
export BG=''
export CYCLE='-cycle'
export FONT='-builtin3'
;;

"dali_small_timer")
export TITLE="-title $ME"
export BG='-bg #00ff00'
export CYCLE='-nocycle'
export FONT='-builtin2'
;;

*)
export TITLE="-title unknown"
export BG='-bg #00ff00'
export CYCLE='-nocycle'
export FONT='-builtin2'
;;
esac

hang_up_the_phone()
{ HPID=$1;
kill -0 $HPID > /dev/null 2>&1 && kill -1 $HPID;
#kill -0 $HPID && kill -1 $HPID;
}

xdaliclock $TITLE $CYCLE $BG $FONT $TARGET &
export BACK1=$!

{
sleep $COUNT ;
kill -1 0
} &
export BACK2=$!

trap "hang_up_the_phone $BACK1 ; \
hang_up_the_phone $BACK2 ; " 0 CHLD;

wait $BACK1 $BACK2
kill -1 0
exit 0
#/sd
# have I gone overboard in my measures to make
# sure the process group all goes away?

* Helmut Waitzmann <nn.throttle@xoxy.net>:
> felix@palmen-it.de (Felix Palmen):
>> The exec() family of functions allows to specify argv[] and the actual
>> executable separately, and this is what happens when executing a script
>> that has a shebang. The binary named in the shebang is executed, but it
>> gets fed the original commandline in argv[], including the original
>> argv[0].
>
> At least, my Debian 10 Linux apparently doesn't follow that part
> of the last sentence that begins with "but it gets fed":  If I
> [...]
> I get the following output:
>
> PPID SID PGID PID STAT argv
> 10075 10075 11141 11141 S+ /bin/sh ./show_args Hello, world!

Well, then I was wrong on that one... happens :o so it's always the
shell "shfiting" argv[] by one when running as an interpreter.

Anyways, what I described is perfectly possible, it's used in other
scenarios for sure.

--
Dipl.-Inform. Felix Palmen <felix@palmen-it.de> ,.//..........
{web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de
{pgp public key} http://palmen-it.de/pub.txt // """""""""""
{pgp fingerprint} 6936 13D5 5BBF 4837 B212 3ACC 54AD E006 9879 F231

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Popping Mad <rainbow@colition.gov> writes:
>> On 4/27/23 12:46, Felix Palmen wrote:
>>> For a script, the script is (logically) the executable, the shell just
>>> acts as an interpreter and will set $0 accordingly.
>>
>> Right, but I would think though, that once #!/bin/bash is reached, that
>> a new shell executatible in formed in ram or on the stack with a new PID
>> and why should it be aware of what happened previously when the $0 is
>> expanded.
>>
>> Do you see my point of confusion?
>
> Not a new shell executable; the executable is the binary file
> "/bin/bash", or whatever. It's a new shell *process*.
>
> It would probably be easier if it consistently expanded to the path
> of the shell executable, but the shell process knows the name of
> the script it's executing (if any), and that information is much
> more useful. In an interactive shell process, there is no script,
> so it falls back to the name of the shell. $0 isn't all that useful
> in an interactive context. The behavior is specified by POSIX.
>
> Here's the relevant wording from the bash manual:
>
> '0'
> ($0) Expands to the name of the shell or shell script. This is set
> at shell initialization. If Bash is invoked with a file of
> commands (*note Shell Scripts::), '$0' is set to the name of that
> file. If Bash is started with the '-c' option (*note Invoking
> Bash::), then '$0' is set to the first argument after the string to
> be executed, if one is present. Otherwise, it is set to the
> filename used to invoke Bash, as given by argument zero.
>
> https://www.gnu.org/software/bash/manual/bash.html
>

excellent - thank you

> or type "info bash" for an interactive view (type 'h' for help if you're
> not familiar with the "info" viewer).
>
> It's also described in the POSIX sh manual under "Special Parameters".
> (It's difficult to search for because it's shown as "0", not "$0".)
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_02
>

On 2023-04-27, Popping Mad <rainbow@colition.gov> wrote:
> On 4/26/23 12:44, Kaz Kylheku wrote:
>> Why would we expect "ps", rather than "grep"?
>
>
> actually, I would think it would be basename, not ps.

Yes; you and Felix are right. I have a blind spot to the insanity
of a basic string-processing function like basename not being
a built-in!

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

felix@palmen-it.de (Felix Palmen):
> * Helmut Waitzmann <nn.throttle@xoxy.net>:
>> felix@palmen-it.de (Felix Palmen):
>>> The exec() family of functions allows to specify argv[] and
>>> the actual executable separately, and this is what happens
>>> when executing a script that has a shebang. The binary named
>>> in the shebang is executed, but it gets fed the original
>>> commandline in argv[], including the original argv[0].
>>
>> At least, my Debian 10 Linux apparently doesn't follow that
>> part of the last sentence that begins with "but it gets fed": 
>> If I
>> [...]
>> I get the following output:
>>
>>
>> PPID SID PGID PID STAT argv
>> 10075 10075 11141 11141 S+ /bin/sh ./show_args Hello, world!
>
> Well, then I was wrong on that one... happens :o so it's always
> the shell "shfiting" argv[] by one when running as an
> interpreter.

The shell examines its argument list, detects, which argument
names the shell script to be read and interpreted, and puts the
value of that argument into the positional parameter "$0".  That
argument doesn't necessarily have to be the argv[1] invocation
argument.  For example, when running a shell script like

sh -x -v - ./show_args 'Hello,' 'world!'

(i. e. with command echoing and tracing enabled and the end of
options explicitly marked) argv[4] will be the name of the script
file "./show_args", and that is what will be available as "$0"
inside of the script.

This mechanism of copying the shell script's name into "$0" is
done by the invoked shell, even if the shell script does not
start with a "#!" line.

As far as I understand it, a member of the "exec" family of
functions, when given a shell script file name as the first
("path" or "file", see the manual page "exec(3)") parameter, for
example

execlp("the_shell_script", "two", "parameters", 0)

(if the variant of the "exec" family function is a "exec…p"
variant and the "the_shell_script" parameter doesn't contain a
slash ("/"), searches for the "the_shell_script" file according
to the "PATH" environment variable, replaces the name by the full
path name of the script file found, for example
"/path/to/the_shell_script"), opens that file for reading, reads
the pathname of the shell to be invoked and an optional parameter
from the

#! /name/of/the/shell optional_parameter

line, and invokes the shell given in that "#!" line (together
with the optional parameter if given) followed by the shell
script pathname and the remaining parameters, like

execl("/name/of/the/shell", "optional_parameter",
"/path/to/the_shell_script", "two", "parameters", 0)