131–140 of 159 posts
I like this but the lazy part of me just treats anything i write into $(mktemp -d) as something that will be eventually GC'd by the operating system. I have no idea when it actually happens, or if it does at all, but that's how i roll.
Earlier quoted context omitted.
SIGABRT would have to come from the process itself; IDK when if ever the shell would do that. And SIGKILL can't be handled, so that is indeed pointless.
In sufficiently old Unix (I remember doing this on 32V) there was a fun little hack you could do with SIGKILL. If you sent SIGKILL to a process and that process was being debugged it would not kill the process. It would just pause it and notify the debugger that the process had received a signal, and tell the debugger which signal. The debugger could then allow the signal to go through to the process as is, or to rep…
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…
Thanks for pointing this quirk/difference out! I'll keep it in mind. Regarding the expected behaviour: I believe this is largely a matter of preference/philosophy. I have previously used trap handlers in bash scripts explicitly so that the cleanup is run in every case and /tmp is not polluted - even of failures. Reasoning: For automated tasks or people not familiar with Linux/my script, the disk should not be filled…
That's perfectly fine – even desirable – behaviour for a whole bunch of use cases. The thing is you can opt-in to that trivially with "trap EXIT INT TERM ABRT", whereas the reverse is harder and much less obvious, so it seems like a better design to me (although a "trap ALWAYS" shortcut would be even better so you don't need to list signals).
At this point it's difficult to change due to compatibility as people's bash scripts would break in subtle ways, but it's one of my many annoyances with bash (my view is that people really ought to ditch bash in favour of a better shell – zsh being the most obvious incremental improvement, though far from the only option – but this always proves to be a controversial opinion).
>The secret sauce is a pseudo-signal provided by bash, called EXIT, that you can trap; commands or functions trapped on it will execute when the script exits for any reason. "Secret Sauce", why is this secret at all. Nothing against the author who's helping the ecosystem here, but is there an authoritative guide on Bash that anyone can recommend? Hopefully something that's portable between Mac & Linux. The web is ful…
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.
Besides, it is slightly ignorant, and if I may say so, it can be a bit neurodivergent.
You see, manual pages are more often than not the wrong type of document to point people to.
`man` pages are information-oriented. You can (or should, if they are well written, which is not always the case, but that's another matter) find all the information about a piece of software there - they are references. As you say, it's something that needs to be digested before you can use it.
There's a certain kind of person, very commonly seen around computers, which can't help but digest a manual before they use a tool. Often they enjoy doing that. And that's fine. But that is not how everyone else does things.
People often have a particular problem they want to solve. They want to know how to zip a whole folder, or generate a ssh key with a particular algorithm. Whatever. Something concrete. They want to solve that, they don't want to "digest a document in order to solve that". That is not something those people enjoy, or are good at.
What those people need is a goal-oriented doc. Something that has a list of possible problems, and then gives solutions. Something that they can search for "whole directory" and find what they are looking for quickly. Something like a FAQ. This does not exist for all command lines (although the `tldr` app fits that well often enough for me).
Blogposts are often (yet another) type of documentation, they are learning-oriented. Like a tutorial.
The thing about blogposts is that they are indexed by Google, Bing and others. So in effect the combination of Google+Blogposts works like a big FAQ document.
Please understand that I am not trying to be offensive here.
Earlier quoted context omitted.
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…
The thing is that reading the manual isn't easy. If it was, everyone would do it, because the benefit is that, eventually, you know every topic or section that appears in the bash man page, and then eventually you know most of what that page says about most of those features. These efforts compound over time. If you reach that point, you know that if you don't know of a feature in that software, it doesn't exist. You…
There's incomplete documentation. There's API documentation without examples (ie specification but no example/tutorial). There's outdated documentation!
I can also say that I started studying SQL by reading the docs for mysql, and after an hour I was still stuck inside INSERT or SELECT. Reading about all use cases in detail was not useful to learn a first approach to the queries!
So I'd say that this "truism" isn't always true. Sometimes the docs suck or don't provide the info you need at that time.
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.
"rtfm" is definitely rude, and always has been. The f does not mean "fun". Besides, it is slightly ignorant, and if I may say so, it can be a bit neurodivergent. You see, manual pages are more often than not the wrong type of document to point people to. `man` pages are information-oriented . You can (or should, if they are well written, which is not always the case, but that's another matter) find all the informatio…
You don't have to be born loving knowing how things work. But if you want to be a programmer (and most people don't) you should accept that the people who understand how things work are eventually going to run rings about people who don't. So you can either cultivate curiosity in how things work, or you can cultivate the habits and fake it till you make it. You put in the work if you want to develop a skill. There's no magic in it.
If you're not interested in being a programmer, then you don't need to waste your time reading man pages, obviously.
Earlier quoted context omitted.
For robust code you should also use set -e. 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 handl…
> For robust code you should also use set -e. Highly debatable.
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.
That said, it makes sense that at least some distros would leave a job in place to do so but initially disabled so that the user can decide based on the use-case
Earlier quoted context omitted.
"rtfm" is definitely rude, and always has been. The f does not mean "fun". Besides, it is slightly ignorant, and if I may say so, it can be a bit neurodivergent. You see, manual pages are more often than not the wrong type of document to point people to. `man` pages are information-oriented . You can (or should, if they are well written, which is not always the case, but that's another matter) find all the informatio…
Wow. What condescending hogwash! You don't have to be born loving knowing how things work. But if you want to be a programmer (and most people don't) you should accept that the people who understand how things work are eventually going to run rings about people who don't. So you can either cultivate curiosity in how things work, or you can cultivate the habits and fake it till you make it. You put in the work if you…
Programming is a vast ocean and very few people are going to know every single detail of ever single nook and cranny. If your day to day involves bash scripts, sure, learn and digest all of them. If you are a python programmer and you just want to compress a file you don't need to know all the flags that `tar` supports.