NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: .cshrc elm and PIDs



    Date:        Mon, 23 Nov 2020 13:09:57 +0000 (UTC)
    From:        steve%prd.co.uk@localhost (Steve Blinkhorn)
    Message-ID:  <20201123130958.2F083B3606D%viking.prd.co.uk@localhost>

  | pgrep -u `id -u` elm 

David Brownless already said that you need >/dev/null on that line
(or perhaps >&/dev/null so stderr gets redirected as well).
That's where the pid is coming from, pgrep outputs the pid of
matching processes.

  | - if elm fails (always because a temporary file alread exists), use CM
  |   (a local alias that removes the temporary file)

Why not just do that before running the first elm? (inside the if).
Does that alias do anything other that remove junk old temp files or
directories?

It isn't that this is wrong, but that if elm exits with bad status
for any other reason (say it gets a hangup signal, or a SIGTERM, or
some other error it cannot recover from - I have never used elm, so I don't
know what might happen) then you're going to start another elm
process (in the case where the first one did not fail to start) which
probably is not what you want to do.

  | BUT the PID for the successful elm process keeps showing up in the
  | text when I'm writing emails,

because of that output from pgrep.   .cshrc is executed every time
a csh starts, and that happens far more often than you'd possibly
expect, for all kinds of purposes, including from some programs
in order to:

  | and ~ substitution doesn't work within elm,

expand the ~  shells know how to do that, so other processes tend
to simply start a shell to get the result rather than programming
it themselves.

So, every time a ~ (or anything else elm or vi happens to use $SHELL
to accomplish) needs to be expanded, a new csh is run, that runs
the .cshrc and as you have it, that output's elm's pid.

The '>/dev/null' should fix all of that - but you might want to
consider whether using .login (or an X startup script) might not
be a better place to do this, rather than simply trying to start elm
any time any csh is run.

  | I'm guessing that umask is internal to csh,

Yes.

  | so elm is the last process to be started from .cshrc.

Probably, but that's not relevant, in the cases that matter it
is already running, will be found by the pgrep, and so not started
again, in those cases the pgrep is the last (or only) process run
from the .cshrc.   Ideally, .cshrc (and $ENV for sh users) shouldn't
be running any processes at all, just doing internal shell setup
(the umask command is a good example of what can be put there).

kre



Home | Main Index | Thread Index | Old Index