flatbush:[ruben]:~$ ps -ef | grep "$(basename "$0")"
* Popping Mad <[email protected]>:
flatbush:[ruben]:~$ ps -ef | grep "$(basename "$0")"
Because you're obviously running that from bash?
I mean, what else would you expect there?
On 4/25/23 07:05, Felix Palmen wrote:
* Popping Mad <[email protected]>:
flatbush:[ruben]:~$ ps -ef | grep "$(basename "$0")"
Because you're obviously running that from bash?
I mean, what else would you expect there?
ps
Popping Mad <[email protected]> writes:
On 4/25/23 07:05, Felix Palmen wrote:
* Popping Mad <[email protected]>:
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.
On 26.04.2023 10:46, Josef Moellers wrote:
On 26.04.23 03:39, Keith Thompson wrote:
Popping Mad <[email protected]> writes:Hint: count the double quotes until you reach the $0, or better yet ...
On 4/25/23 07:05, Felix Palmen wrote:
* Popping Mad <[email protected]>:
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.
toggle "inside"/"outside" each time you encounter one.
To "toggle" is a wrong advice _here_; for nested subshells,
like "$(basename "$0")" it is _counting_.
On 26.04.23 03:39, Keith Thompson wrote:
Popping Mad <[email protected]> writes:Hint: count the double quotes until you reach the $0, or better yet ... toggle "inside"/"outside" each time you encounter one.
On 4/25/23 07:05, Felix Palmen wrote:
* Popping Mad <[email protected]>:
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.
or nested subshells,
like "$(basename "$0")" it is _counting_.
On 4/26/23 05:16, Janis Papanagnou wrote:
or nested subshells,
like "$(basename "$0")" it is _counting_.
counting what?
On 4/26/23 05:16, Janis Papanagnou wrote:
or nested subshells,
like "$(basename "$0")" it is _counting_.
counting what?
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
On 4/25/23 07:05, Felix Palmen wrote:
* Popping Mad <[email protected]>:
flatbush:[ruben]:~$ ps -ef | grep "$(basename "$0")"
Because you're obviously running that from bash?
I mean, what else would you expect there?
ps
Popping Mad <[email protected]> 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.
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.
On 2023-04-26, Popping Mad <[email protected]> wrote:
On 4/25/23 07:05, Felix Palmen wrote:
* Popping Mad <[email protected]>:
flatbush:[ruben]:~$ ps -ef | grep "$(basename "$0")"
Because you're obviously running that from bash?
I mean, what else would you expect there?
ps
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"?
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 tryinghttp://mywiki.wooledge.org/ProcessManagement#How_do_I_make_sure_only_one_copy_of_my_script_can_run_at_a_time.3F
to do something specific (apparently filtering the output of `ps -ef`),
you need to tell us what your goal is.
Why would we expect "ps", rather than "grep"?
And then, we should finally see how $0 would be utterly pointless if
*not* expanded by the shell ;)
Again, the whole point of threads like this is for us to guess at what OP's real problem is
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.
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.
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.
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.
For a script, the script is (logically) the executable, the shell just
acts as an interpreter and will set $0 accordingly.
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
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?
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.
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.
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?
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?
* Popping Mad <[email protected]>:
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).
On Thu, 27 Apr 2023 00:55:53 -0400 Popping Mad <[email protected]>
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
[email protected] (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!
Popping Mad <[email protected]> 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
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.
* Helmut Waitzmann <[email protected]>:
[email protected] (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.
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).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 05:39:12 |
| Calls: | 12,100 |
| Calls today: | 8 |
| Files: | 15,003 |
| Messages: | 6,517,909 |
| Posted today: | 1 |