Re: Feature request: process title with exec -a "" for oneself

[Chet Ramey]

On 9/4/24 5:54 PM, Emanuele Torre wrote:


Not super relevant, but I have a bash loadable builtin that can set the
script's proctitle that I wrote for fun ~1 year ago.


I think this is appropriate for a loadable builtin. This one is Linux-
specific.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: 'wait -n' with and without id arguments

[Chet Ramey]

On 8/30/24 11:06 PM, Zachary Santer wrote:

CWRU/CWRU.chlog:
 >    8/26
 >    

 > execute_cmd.c
 > [...]
 > - execute_connection: in default mode, bash performs jobs notifications
 >   in an interactive shell between commands separated by ';' or '\n'.
 >   It shouldn't do this in posix mode, since posix now specifies when
 >   notifications can take place

I forgot your comment below about the shell not being interactive any time 
it's not accepting input from the user and took this to mean that 'jobs' 
notifications would only ever be printed immediately prior to a prompt when 
bash is in posix mode. I don't understand what posix mode changes relative 
to the existing behavior if not that.


In default mode, bash prints job notifications when executing a list (it
calls lists `connections' internally). Commands in lists can be delimited
by a `;' or newline; bash performs notifications between executing, say,
the left and right sides of `command 1; command 2'. Now it doesn't do that
in posix mode. It still does job notifications in other places that aren't
strictly posix conformant.



 > jobs.c
 > - notify_and_cleanup: make interactive shells notifying during sourced
 >   scripts dependent on the shell compatibility level and inactive in
 >   versions beyond bash-5.2
 >   Inspired by report from Zachary Santer >


Making 'jobs' notifications not happen while the interactive shell is 
sourcing a script misses the cases where a function is otherwise executed 
directly from the command line and of course a whole bunch of commands 
separated by semicolons entered in one command line.


What behavior do you want from the command lists that differs from what I
described above? Since shell functions are essentially lists, you should
get the same behavior from both.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: 'wait -n' with and without id arguments

[Chet Ramey]

On 8/30/24 11:06 PM, Zachary Santer wrote:


New wait-n-failure attached.


I'll look at this. These always take a long time.

(Apparently ${SECONDS} can't be declared local 
and still work.)


Making a variable local removes the special behavior on assignment and
reference.


$ source ~/random/wait-n-failure run monitor
run true
explicit_pids false
monitor true
notify false
posix false
bash 5.3.0(1)-alpha
[5]+  Done                       wait-n-failure_random_sleep
[1]   Done                       wait-n-failure_random_sleep
[2]   Done                       wait-n-failure_random_sleep
[3]   Done                       wait-n-failure_random_sleep
[4]-  Done                       wait-n-failure_random_sleep
[5]-  Done                       wait-n-failure_random_sleep
[6]-  Done                       wait-n-failure_random_sleep
[7]-  Done                       wait-n-failure_random_sleep
[8]   Done                       wait-n-failure_random_sleep
[9]   Done                       wait-n-failure_random_sleep
[10]+  Done                       wait-n-failure_random_sleep
[1]+  Done                       wait-n-failure_random_sleep
[1]+  Done                       wait-n-failure_random_sleep
[1]+  Done                       wait-n-failure_random_sleep
[... All following "Done" notifications are for jobs with job id 1.]
96 processes waited / 100 processes forked
11 seconds

I did not expect to see job notifications here. The changelog seems pretty 
clear that there shouldn't be any. 


There are other code paths where the shell notifies, and this is probably
one of them. I will take a look at where. Certainly the conditions under
which the shell notifies about changed job status should be consistent.


On Mon, Aug 26, 2024 at 10:57 AM Chet Ramey > wrote:

 >
 > On 8/14/24 11:22 PM, Zachary Santer wrote:
 > > On Wed, Aug 14, 2024 at 3:22 PM Chet Ramey > wrote:

 > >>
 > >> On 8/7/24 2:47 PM, Zachary Santer wrote:
 > >
 > >>> If you want the behavior of 'wait -n' to be
 > >>> consistent between scripts and the interactive shell, then it should
 > >>> choose one terminated child process from the list of those that is
 > >>> maintained in the interactive shell, if it's nonempty, to report to
 > >>> the user and to clear from that list, any time it is called.
 > >>
 > >> I'm not sure returning the status of some random process from some
 > >> arbitrary point in the past is going to be valuable.
 > >
 > > I think the value is in the consistent behavior of 'wait -n', which
 > > this would provide. If the user is intent on running 'wait -n' without
 > > id arguments in the interactive shell, they can ensure that child
 > > processes forked long ago are ignored by simply calling 'wait' without
 > > -n before moving on to what they're trying to do.
 >
 > Sure, they can do that. That's a new requirement, though.

I've seen you point out "I can't imagine why a person would do X, so it 
must never happen" as being fallaciou. 


I'm sure I've been guilty of it myself.

However, I think the benefit to 
consistent behavior far outweighs the hardship caused to whoever would 
write a script intended for use within the interactive shell that depends 
on 'wait -n' without id arguments ignoring background processes that the 
user has already been notified of via the 'jobs' output.


Consider programmable completion frameworks, commands executed via
`bind -x', or traps (e.g., DEBUG) intended to provide enhancements to
the standard behavior, all of which exist and have generated reports or
requests for features.

People put pretty complicated stuff into PROMPT_COMMAND and other prompts,
too.

We don't know how the existing uses would be affected by changes until I
make them.

If the behavior here isn't modified, the man page really should note that 
'wait -n' without id arguments won't return the termination status of a 
child process that has already been notified through the 'jobs' output. 


That is exactly the behavior posix seems to require (`wait -n' aside, but
see below): once you notify the user, you delete the job and it disappears
forever. Bash doesn't delete jobs like that in all cases, and that's the
source of at least kre's objections (as you note below).

The only real question is when (and under what circumstances) you do the
notification, and that's what we're trying to hash out.



 > > On Wed, Aug 14, 2024 at 4:44 PM Robert Elz > wrote:

 > >>
 > >>    | Maybe the thing to do is to retain jobs in the job list, even after
 > >>    | they're marked as notified,
 > >>
 > >> I'd do the opposite, once they're notified, they should be deleted
 > >> from the jobs table, and everywhere else.   But "notified" only happens
 > >> when the script explicitly asks (in a non-interactive shell, never 
because

 > >> of any other event than an appropriate command issued by the script, and
 > >> in an interactive shell, the same, or the implicit "jobs" b

Re: Feature request: process title with exec -a "" for oneself

[Lockywolf]

Chet Ramey  writes:

> So I assume that you want to change the kernel's idea of the process
> arguments as seen and displayed by `ps'. If so, I'm not really interested
> in adding that as a feature. It doesn't seem to add anything for shell
> users.

Well, I am a shell user :).

I would really love to have such a feature because I have two use-cases
for it.

1. I would use it as a super minimalist progress indicator for one-shot
scrips written with little consideration.

For example, I sometimes find myself writing something like:
`while true; do try_something_slow && exit 0 ; sleep 1 ; done &`

With a setproctitle I would write something like:

`I=0 ; while true; do try_something_slow && exit 0 ; I=$((I + 1)) ;
setproctitle "trier_$I-times" sleep 1 ; done &`

And this leaves no lingering files, does not require finding a PID to
look at `/proc/$pid/environ`, et cetera. I can just query the progress
using `ps`.

2. I would use it to distinguish subshells from the current script in
`ps`.

By default a subshell has the same name as the parent shell.
So when I run `ps/pgrep`, I often get processes with the same name, and
I'd have to parse the output of `pstree` to find out which is which.
And running exec -a "${BASH_ARGV0}_child" while true ; do sleep 1 ; done &
is not a valid syntax.

I think this would greatly simplify debugging shell scripts, but maybe
it's just me.

>I think this is appropriate for a loadable builtin. This one is Linux-
>specific.

I am not experienced enough to have an opinion on whether a loadable
built-in is better than a feature of "exec".

-- 
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)


signature.asc
Description: PGP signature

Re: Feature request: process title with exec -a "" for oneself

[Emanuele Torre]

On Fri, Sep 06, 2024 at 08:37:54AM +0800, Lockywolf wrote:
> >I think this is appropriate for a loadable builtin. This one is Linux-
> >specific.
> 
> I am not experienced enough to have an opinion on whether a loadable
> built-in is better than a feature of "exec".

A loadable builtin is a builtin developed independently from bash, that
can be loaded into the shell with the "enable" command.  Kind of like
python modules.

o/
 emanuele6