91–100 of 159 posts
Earlier quoted context omitted.
Some temporary file remover. Lol indeed
The nice thing about temp files is that the OS will eventually remove them, even if you don't
with UNIX/POSIX systems it pays to say "it depends" often.
```
failure() {
local lineno="$1"
local msg="$2"
echo "Failed at ${lineno}: ${msg}"
trap 'failure "$LINENO" "BASH_COMMAND"' ERR
```
Earlier quoted context omitted.
It's secret enough to be well documented in the man page. The real question is, why do people look to random web pages prior to having digested everything in the manual? People used to say "rtfm" all the time, this would be regarded as shockingly rude in today's tech culture but it was a valuable public service to have it repeated, like being reminded to eat your vegetables.
Because ain't nobody got time for that. ;) More seriously, I think that we have been trained to rely on just in time searches (or ChatGPT sessions) when we encounter the next thing we need to learn. RTFM is just so time consuming and I personally don't recall everything I have read, leading me to rely on search/AI to re-learn the next thing just in time anyways. In some ways this is a vast improvement, which is why i…
You can spend twice as much time over twice as many years reading random blog posts and googling, and you'll have no cohesive, comprehensive picture of the full tool and all its features. In this case, if you look at `man bash` and find the trap builtin function you'll learn about the DEBUG and ERR traps, for example, which I didn't see mentioned in the discussion here. These things might be useful to just file away; in case you ever need it someday, then you'll know it's there and exactly where to find it, not some half-remembered blog post you can't find again.
Over ten or twenty years, the difference between these two habits is night and day. The people who read the documentation first, and only then ask for help, and the people who ask for help first and get it and so never read the docs, end up in a totally different place with respect to overall confidence and comfort with the tools. Reading the man page means you don't get your answer right away, it's slower, less enjoyable, and less fun than googling. It's competing with content that was literally filtered by an engagement selection process. Of course it's less immediate gratification. The only reason people will do it is if they internalize the habit long enough to appreciate the benefits.
"RTFM" was a bit of social shaming, to tell people "don't be lazy, the answer you seek is literally in the documentation, please just read it". Shaming strangers on the internet turns out to not work well at scale, so generally we don't do this now, and the message just doesn't get passed on at all.
I've been shocked at the attitude even in some companies that reading docs is some kind of unnecessary or obsolete practice. As you say, it's become the default option to seek answers online. A culture of reading documentation still exists, but now it has to be maintained inside organizations that care about it, because it's no longer understood as the basic professional attitude.
Earlier quoted context omitted.
What's the signal for SIGKILL?
SIGKILL can't be handled. It's the signal you send when you don't want to give the process a chance to handle it.
Earlier quoted context omitted.
SIGKILL can't be handled. It's the signal you send when you don't want to give the process a chance to handle it.
That's the difference between kill -15 (SIGTERM) and kill -9 (SIGKILL), where SIGTERM shuts down a process gracefully.
Earlier quoted context omitted.
POSIX says that "setting a trap for SIGKILL or SIGSTOP produces undefined results", but for signals it describes SIGKILL as "Kill (cannot be caught or ignored)". I'm guessing this is some relic from 80s Unix systems where SIGKILL behaved different, or perhaps just an inconsistency/oversight.
I read that as undefined in terms of how the shell itself handles it, because the OS doesn't care.
Should go without saying, but don't rely on this for anything critical. It's not guaranteed this will run, even on successful completion of the script. Simple example: power is cut between the last line of the script and before the trap runs. Just a heads up
Earlier quoted context omitted.
The nice thing about temp files is that the OS will eventually remove them, even if you don't
Only if Cron is set up to do it. I have hosts without /tmp and /var/tmp clearance and they have data states which persist across reboot. with UNIX/POSIX systems it pays to say "it depends" often.
An annoying thing about bash is that EXIT will also run on SIGINT (^C), which most other shells won't (in my reading it's also not POSIX compliant, although the document is a bit vague). Some might argue this is a feature, but IMHO it's a bug – sometimes you really don't want cleanup to happen so people can inspect the contents of temporary files for debugging. Because trap doesn't pass the signal information to the…
> Because trap doesn't pass the signal information to the handler You can examine $? on entry to the trap function. On signals, it will be 128 + signal. i.e. on TERM (15) it will be 143. On INT (2) it will be 130. #!/bin/bash skip_exit= on_exit() { code=$? if test $code == 130; then skip_exit=1 fi if test -n "$skip_exit"; then return fi echo "Exiting with: $code" return $code } trap on_exit INT EXIT sleep 2 false Wit…
This changes things again. Often a process started by the shell will get the signal, too (depends of course on how it is sent) and exit with a non-zero return value (depends on the process of course). I believe (not at the computer right now) the handler for EXIT is called in that case.
Was it so that bash can also trap ERR, but dash cannot?
It's not perfectly easy to handle all possible cases, and certainly impossible in a fully portable way.