4 ms·
I use a few of these regularly: ts timestamps each line of the input, which I've found convenient for ad-hoc first-pass profiling in combination with verbose p
by JoshTriplett 5y ago
I use a few of these regularly:
ts timestamps each line of the input, which I've found convenient for ad-hoc first-pass profiling in combination with verbose print statements in code: the timestamps make it easy to see where long delays occur.
errno is a great reference tool, to look up error numbers by name or error names by number. I use this for two purposes. First, for debugging again, when you get an errno numerically and want to know which one it was. And second, to search for the right errno code to return, in the list shown by errno -l.
And finally, vipe is convenient for quick one-off pipelines, where you know you need to tweak the input at one point in the pipeline but you know the nature of the tweak would take less time to do in an editor than to write the appropriate tool invocation to do it.
- ducktective 5y agoI actually installed moreutils just for errno, but I got disappointed. Here it the whole `errno -l` : http://ix.io/3VeV http://ix.io/3VeV Like, none of the everyday tools I use produce exit codes which correspond to these explanations. For my scripts, I just return 1 for generic erros and 2 for bad usage. I wished I could be more specific in that and adhered to some standard.
- JoshTriplett 5y agoerrno codes aren't used in the exit codes of command-line tools; they're used in programmatic APIs like syscalls and libc functions. There's no standard for process exit codes, other than "zero for success, non-zero for error".
- zzo38computer 5y agoSome programs do follow a specification (sysexits.h) where numbers 64 and higher are used for common uses, such as usage error, software error, file format error, etc.
- ithkuil 5y agoAldo when the oomkiller process kills another process it causes it to exit with a well known exit code: 137
- saagarjha 5y agoThat’s just 128+SIGKILL (9).
- teddyh 5y agoThat’s not an exit code; that is a fake exit code which your shell made up, since your shell has no other way to tell you that a process did not exit at all, but was killed by a signal (9, i.e. SIGKILL). This is, again, not an actual exit code, since the process did not actually exit. See here for why you can’t use an exit status of 128+signal to fake a “killed by signal” state, either: https://www.cons.org/cracauer/sigint.html https://www.cons.org/cracauer/sigint.html
- teddyh 5y agoThat is not entirely true. There is sysexits.h, which tried to standardize some exit codes (originally meant for mail filters). It is used by, for instance, argp_parse(). https://sourceware.org/git/?p=glibc.git;a=blob;f=misc/sysexits.h https://sourceware.org/git/?p=glibc.git;a=blob;f=misc/sysexi...
- drewg123 5y agoIts a shame errno is even needed, and is one of my pet peeves about linux. On linux, errno.h is fragmented across several places because errnos are different on different architectures. I think this started because when Linus did the initial alpha port, he bootstrapped Linux using a DEC OSF/1 userland, which meant that he had to use the DEC OSF/1 BSD-derived values of errno rather than the native linux ones so that they would run properly. I'm not sure why this wasn't cleaned up before it made it into the linux API on alpha. At least on FreeBSD, determining what errno means what is just a grep in /usr/include/sys/errno.h. And it uses different errnos for different ABIs (eg, linux binaries get their normal errnos, not the FreeBSD ones).
- tedunangst 5y agoFreebsd doesn't have man errno??
- drewg123 5y agoIt does, but its easier to grep for the number in a errno.h
- bakul 5y agoI’ve used this for years: errno () { grep \\\<$*\\\> /usr/include/sys/errno.h } There will be a false positive now & then but this is good enough.