why bash in $0 ?

[Popping Mad]

flatbush:[ruben]:~$ ps -ef | grep "$(basename "$0")"
root 339 2991 0 Apr09 tty3 00:00:00 -bash
ruben 1091 1090 0 Apr24 pts/5 00:00:00 -bash
ruben 7745 7743 0 Apr19 pts/8 00:00:00 bash
ruben 8999 8996 0 Apr17 pts/4 00:00:00 bash
ruben 9260 9258 0 Apr24 pts/1 00:00:00 bash
ruben 14427 14425 0 06:10 pts/6 00:00:00 bash
ruben 18922 14427 0 06:46 pts/6 00:00:00 grep --colour=auto bash
ruben 28570 28569 0 Apr24 pts/3 00:00:00 -bash
ruben 30315 30314 0 Apr24 pts/2 00:00:00 -bash
ruben 30844 30842 0 Apr23 pts/0 00:00:00 bash
ruben 31263 2986 0 Mar17 tty2 00:00:00 -bash

[Felix Palmen]

* Popping Mad <rai...@colition.gov>:

> flatbush:[ruben]:~$ ps -ef | grep "$(basename "$0")"

Because you're obviously running that from bash?

I mean, what else would you expect there?

--
Dipl.-Inform. Felix Palmen <fe...@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

[Popping Mad]

On 4/25/23 07:05, Felix Palmen wrote:
> * Popping Mad <rai...@colition.gov>:
>> flatbush:[ruben]:~$ ps -ef | grep "$(basename "$0")"
>
> Because you're obviously running that from bash?
>
> I mean, what else would you expect there?
>

ps

[Keith Thompson]

"$0" is expanded by the bash process, not by the ps process.

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

[Josef Moellers]

On 26.04.23 03:39, Keith Thompson wrote:
> Popping Mad <rai...@colition.gov> writes:
>> On 4/25/23 07:05, Felix Palmen wrote:
>>> * Popping Mad <rai...@colition.gov>:
>>>> flatbush:[ruben]:~$ ps -ef | grep "$(basename "$0")"
>>>
>>> Because you're obviously running that from bash?
>>>
>>> I mean, what else would you expect there?
>>>
>>
>>
>> ps
>
> "$0" is expanded by the bash process, not by the ps process.
>

Hint: count the double quotes until you reach the $0, or better yet ...
toggle "inside"/"outside" each time you encounter one.
NB Not that the double quotes will prevent the $0 from bein expanded
when seen!

Josef

[Janis Papanagnou]

On 26.04.2023 10:46, Josef Moellers wrote:
> On 26.04.23 03:39, Keith Thompson wrote:
>> Popping Mad <rai...@colition.gov> writes:
>>> On 4/25/23 07:05, Felix Palmen wrote:
>>>> * Popping Mad <rai...@colition.gov>:
>>>>> flatbush:[ruben]:~$ ps -ef | grep "$(basename "$0")"
>>>>
>>>> Because you're obviously running that from bash?
>>>> I mean, what else would you expect there?
>>>
>>> ps
>>
>> "$0" is expanded by the bash process, not by the ps process.
>>
> Hint: count the double quotes until you reach the $0, or better yet ...
> toggle "inside"/"outside" each time you encounter one.

To "toggle" is a wrong advice _here_; for nested subshells,
like "$(basename "$0")" it is _counting_.

Janis

[Josef Möllers]

I stand corrected!

Josef

[Popping Mad]

On 4/26/23 05:16, Janis Papanagnou wrote:
> or nested subshells,
> like "$(basename "$0")" it is _counting_.

counting what?

[Josef Möllers]

"count the double quotes"

Josef

[Janis Papanagnou]

Josef mentioned two cases; toggling and counting [of quotes].

Example for case 1, toggling: x="ab cd"*"de fg"
the first quote gets closed by the second one, unquoted *,
the third one gets closed by the fourth one.

Example for case 2, counting: echo "$(basename "$0")"
the $(...) subshell expansion opens its own new embedded
"quote space", so the first quote is closed by the fourth,
and the second one by the third.
"$(
"$0"
)"

Janis

[Keith Thompson]

I don't think you ever said what you're trying to accomplish. If your
question was based on idle curiousity, that's fine, but if you're trying
to do something specific (apparently filtering the output of `ps -ef`),
you need to tell us what your goal is.

[Kenny McCormack]

In article <87cz3qe...@nosuchdomain.example.com>,

Keith Thompson <Keith.S.T...@gmail.com> wrote:
>Popping Mad <rai...@colition.gov> writes:
>> flatbush:[ruben]:~$ ps -ef | grep "$(basename "$0")"
>> root 339 2991 0 Apr09 tty3 00:00:00 -bash
>> ruben 1091 1090 0 Apr24 pts/5 00:00:00 -bash
>> ruben 7745 7743 0 Apr19 pts/8 00:00:00 bash
>> ruben 8999 8996 0 Apr17 pts/4 00:00:00 bash
>> ruben 9260 9258 0 Apr24 pts/1 00:00:00 bash
>> ruben 14427 14425 0 06:10 pts/6 00:00:00 bash
>> ruben 18922 14427 0 06:46 pts/6 00:00:00 grep --colour=auto bash
>> ruben 28570 28569 0 Apr24 pts/3 00:00:00 -bash
>> ruben 30315 30314 0 Apr24 pts/2 00:00:00 -bash
>> ruben 30844 30842 0 Apr23 pts/0 00:00:00 bash
>> ruben 31263 2986 0 Mar17 tty2 00:00:00 -bash
>
>I don't think you ever said what you're trying to accomplish.

That is standard for these kinds of questions. To tell, would give the
game away.

>If your question was based on idle curiosity, that's fine, but if you're

>trying to do something specific (apparently filtering the output of `ps
>-ef`), you need to tell us what your goal is.

Again, the whole point of threads like this is for us to guess at what OP's
real problem is (if indeed, there is any and it is not just trolling). And
to fight amongst ourselves over whose interpretation is correct. As we are
now doing.

--
If you ask a Trumper who is to blame for the debacle of Jan 6, they will almost certainly say
something about Antifa/BLM/something/whatever. This shows just how screwed up they are; they can't
even get their narrative straight. What they *should* say is "Eugene Goodman". If not for him, the plot
would probably have succeeded, so he (Eugene) is clearly to blame for the failure.

[Kaz Kylheku]

Let's assume we have no idea that $0 is expanded by the shell before
it executes the command.

Why would we expect "ps", rather than "grep"?

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

[Felix Palmen]

* Kaz Kylheku <864-11...@kylheku.com>:

> On 2023-04-26, Popping Mad <rai...@colition.gov> wrote:
>> On 4/25/23 07:05, Felix Palmen wrote:
>>> * Popping Mad <rai...@colition.gov>:
>>>> flatbush:[ruben]:~$ ps -ef | grep "$(basename "$0")"
>>>
>>> Because you're obviously running that from bash?
>>>
>>> I mean, what else would you expect there?
>>
>> ps

I see, this is an attempt to "reuse" a commandline, right? I mean,
"grep ps" would be horrible "hardcoding" ^^

> Let's assume we have no idea that $0 is expanded by the shell before
> it executes the command.
>
> Why would we expect "ps", rather than "grep"?

Then why "grep", rather than "basename"?

And then, we should finally see how $0 would be utterly pointless if
*not* expanded by the shell ;)

[Popping Mad]

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.

[Popping Mad]

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.

[Popping Mad]

On 4/26/23 12:09, Keith Thompson wrote:
> I don't think you ever said what you're trying to accomplish. If your
> question was based on idle curiousity, that's fine, but if you're trying
> to do something specific (apparently filtering the output of `ps -ef`),
> you need to tell us what your goal is.

http://mywiki.wooledge.org/ProcessManagement#How_do_I_make_sure_only_one_copy_of_my_script_can_run_at_a_time.3F

[Popping Mad]

On 4/26/23 12:38, Kenny McCormack wrote:
> Again, the whole point of threads like this is for us to guess at what OP's
> real problem is

No - but the cynicism is appreciated. It is ACTUALLY an attempt to
understand how it works with no specific task in mind.

[Popping Mad]

On 4/26/23 12:09, Keith Thompson wrote:

> I don't think you ever said what you're trying to accomplish. If your
> question was based on idle curiousity, that's fine, but if you're trying
> to do something specific (apparently filtering the output of `ps -ef`),
> you need to tell us what your goal is.

It was an example I read somewhere that I tried to execute in order to
understand it...

[Popping Mad]

On 4/26/23 12:09, Keith Thompson wrote:

> I don't think you ever said what you're trying to accomplish. If your
> question was based on idle curiousity, that's fine, but if you're trying
> to do something specific (apparently filtering the output of `ps -ef`),
> you need to tell us what your goal is.

[Spiros Bousbouras]

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

[Janis Papanagnou]

[ Post concerning expansion of basename "$0" ]

Ah, I see, thanks for clarifying. - This assumes that $0 is expanded
by the command using it as argument, i.e. the MD DOS approach; every
(raw!) text data passed with the call is expanded by the respective
command, so [in DOS] every command has to implement or call the same
argument parsing routines. - Unix shells are different; the shell is
doing expansions (typically expansions can be spotted by a '$', like
$var, ${var}, $(cmd), $((expr)), etc., or by the file globbing, *, ?,
[...], etc.) and the _expanded_ text is passed to the program. So in
basename "$0" ; ls x* ; # etc. (for example)
The command basename sees what is expanded by the shell (from where
you called it), ls sees what files the shell matched and provides an
expanded matching files list (unless there's no match, in that case
the literal 'x*' is passed). So an argument expansion with a $ will
not be seen literally by the program unless it is single quoted or
the $ escaped ('$0' or \$0). (The double quoting has also yet more
semantics (as opposed to no quoting), BTW; also important to know,
see "field-splitting" in the docs.)

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.

Janis

[Popping Mad]

On 4/27/23 04:33, Spiros Bousbouras wrote:
> 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

Thank you.

But I fail to see the mechanism that would make that happen like that.
Why does it make a different from the command line than from a script?

[Felix Palmen]

* Popping Mad <rai...@colition.gov>:

> But I fail to see the mechanism that would make that happen like that.
> Why does it make a different from the command line than from a script?

For a script, the script is (logically) the executable, the shell just
acts as an interpreter and will set $0 accordingly.

When you just type commands in an interactive shell, there's no
executable. Well, besides the shell itself of course.

[Popping Mad]

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?

[Popping Mad]

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

[Felix Palmen]

* Popping Mad <rai...@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.

[David W. Hodgins]

On Thu, 27 Apr 2023 12:53:46 -0400, Popping Mad <rai...@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

[Janis Papanagnou]

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.

===

[Keith Thompson]

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

[Helmut Waitzmann]

fe...@palmen-it.de (Felix Palmen):
> * Popping Mad <rai...@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\!

[vallor]

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 <val...@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?

[Felix Palmen]

* Helmut Waitzmann <nn.th...@xoxy.net>:
> fe...@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.

[Ruben Safir]

excellent - thank you

[Kaz Kylheku]

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!

[Helmut Waitzmann]

fe...@palmen-it.de (Felix Palmen):

> * Helmut Waitzmann <nn.th...@xoxy.net>:
>> fe...@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)

[Popping Mad]

On 4/27/23 06:34, Janis Papanagnou wrote:

> s sees what files the shell matched and provides an
> expanded matching files list (unless there's no match, in that case
> the literal 'x*' is passed).

flatbush:[ruben]:~$ cd ~/mnt/ ; ls *
AVF_INFO:
AVIN0001.BNP AVIN0001.INP AVIN0001.INT PRV00001.BIN

that lists the subdirectory