Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hints for writing Unix tools

monkey.org

Post reply on HN
Print view View original

61–70 of 131 posts

Re: Hints for writing Unix tools

#61

Post by to3m »

fragmede wrote: post #10
to3m wrote: post #7

Additional tip: if writing a tool that prints a list of file names, provide a -0 option that prints them separated by '\x0' rather than white space. Then the output can be piped through xargs -0 and it won't go wrong if there are files with spaces in their paths. I suggest -0 for symmetry with xargs. find calls it -print0, I think. (In my view, this is poor design on xargs's part; it should be reading a newline-separ…

> newline-separated list of unescaped file names That breaks when you have newlines in filenames, no?

File names often have spaces in them, but very rarely newlines. Based on xargs's current behaviour, it's clearly no problem to just not support certain characters in file names by default. I just think it would have been more useful for it to not support a smaller set of names.

Re: Hints for writing Unix tools

#62

Post by edwintorok »

userbinator wrote: post #43
dap wrote: post #27

Earlier quoted context omitted.

IMO, this is an anti-pattern. It's violates the principle of least surprise. (How come I see X when I run the command, but I can't grep for X in its output? How come it works when I run it from my interactive shell, but it's broken when I run it from a script? And things like that.)

I agree, especially for the behaviour from the parent: "ps -f" truncates long lines instead of wrapping, while "ps -f | cat" lets the long lines live How people usually discover what these commands do is by running them interactively, and if that results in some output being hidden vs being run noninteractively, then they have little reason to believe that it could yield more output than what they're used to seeing.…

On a quick look through ps's manpage I couldn't find anything about this. Am I missing something?

Re: Hints for writing Unix tools

#63

Post by chriswarbo »

burke wrote: post #28
dap wrote: post #27

Earlier quoted context omitted.

IMO, this is an anti-pattern. It's violates the principle of least surprise. (How come I see X when I run the command, but I can't grep for X in its output? How come it works when I run it from my interactive shell, but it's broken when I run it from a script? And things like that.)

I think it depends what sort of things you use it for. I often use it to switch on or off ANSI colourization, which doesn't really violate the principle of least surprise. When used sparingly and thoughtfully, I've never personally had an issue with it.

You may not have issue with the sort of things you use it for, but others might.

For example, I run shells in Emacs and have had to tweak loads of shell scripts written by colleagues to fix their poorly-implemented colourisation. It's useful to know when a test has failed; it's not so useful to have the whole terminal set to white text on a pale pink background.

One day I couldn't SSH into our servers from Emacs. It turned out somebody had edited .bashrc for the admin user to make the bash prompt blue. Emacs' TRAMP process was looking for a prompt ending in "$" or "#", not "$\[\033[0m\]", so it didn't realise the connections were successful.

There are two ways of handling this: we can blame the source of the bug (the person adding the colours incorrectly, or the assumption-loaded TRAMP regex), but there will always be more bugs in situations we'd never think of. Alternatively, we can avoid being 'too clever', and instead aim for consistency and least surprise.

Re: Hints for writing Unix tools

#64

Post by mjevans »

to3m wrote: post #61
fragmede wrote: post #10

Earlier quoted context omitted.

> newline-separated list of unescaped file names That breaks when you have newlines in filenames, no?

File names often have spaces in them, but very rarely newlines. Based on xargs's current behaviour, it's clearly no problem to just not support certain characters in file names by default. I just think it would have been more useful for it to not support a smaller set of names.

You would be amazed what various broken tools can produce for filenames.

Re: Hints for writing Unix tools

#65

Post by edwintorok »

jwr wrote: post #55

I would add to this list: If you are intercepting UNIX signals (starting with SIGINT), go back to the drawing board and think again. Don't do it. There is almost never a good reason for doing it, and you will likely get it wrong and frustrate users.

How about cleaning up tempfiles on ^C?

Re: Hints for writing Unix tools

#66

Post by mjevans »

deathanatos wrote: post #23
pstuart wrote: post #15

Earlier quoted context omitted.

> That breaks when you have newlines in filenames, no? That seems like an extremely pathological case.

> That seems like an extremely pathological case. When a human is creating files by hand, I almost certainly agree. When a program is creating files, however, it's only a matter of time before weird characters wind their way in there. I really wish newlines had been disallowed. (There's UI implications, in addition to the parsing ones — how do you do a list view with newlines in the filename?; I also wish filenames h…

UI issues; on display format all /printing display elements/ (including spaces as spaces and things that look like whitespace but aren't spaces) with readable glyphs, or those numeric standins for non-rendering glyphs.

Re: Hints for writing Unix tools

#67

Post by [deleted] »

edwintorok wrote: post #65
jwr wrote: post #55

I would add to this list: If you are intercepting UNIX signals (starting with SIGINT), go back to the drawing board and think again. Don't do it. There is almost never a good reason for doing it, and you will likely get it wrong and frustrate users.

How about cleaning up tempfiles on ^C?

[deleted]

Re: Hints for writing Unix tools

#68

Post by foobarbaz1234 »

osandov wrote: post #25

A nitpicky tip: --help is normal execution, not an error, so the usage information should be printed to stdout, not stderr (and it should exit with a successful status). Nothing is more annoying than trying to use a convoluted program with a million flags (which should have a man page in the first place) and piping --help into less with no success.

I am not so sure with that. Say, your program is used in a shell script and is invoked badly - you might want to print its usage then. If you exit normally your shell script might break weirdly but if you exit with error it's easier to spot the reason of failure.

On the other hand you made me thinking and probably you should have three code passes per default:

  [0] normal behaviour (exit 0)
  [1] bad arguments (exit EINVAL)
  [2] --usage (print to stdout but but exit != 0)?
Anyway I am not sure if it makes sense to declare "usage" as normal behaviour.

Re: Hints for writing Unix tools

#69

Post by JetSpiegel »

acabal wrote: post #3

Great article. The other thing I've always wished for command-line tools is some kind of consistency for flags and arguments. Kind of like a HIG for the command line. I know some distros have something like this, and that it's not practical to do as many common commands evolved decades ago and changing the interface would break pretty much everything. But things like `grep -E,--extended-regexp` vs `sed -r,--regexp-ex…

It would be easier to write a wrapper that called the real commands. You would have to writer a wrapper for each command, so it's still a lot of work.

Re: Hints for writing Unix tools

#70

Post by JetSpiegel »

dTal wrote: post #57
acabal wrote: post #3

Great article. The other thing I've always wished for command-line tools is some kind of consistency for flags and arguments. Kind of like a HIG for the command line. I know some distros have something like this, and that it's not practical to do as many common commands evolved decades ago and changing the interface would break pretty much everything. But things like `grep -E,--extended-regexp` vs `sed -r,--regexp-ex…

I've often thought this - that xkcd.com/1168/ is funny is a terrible embarrassment. I would also like to add that manpage syntax help should be standardized and machine-parseable. I had an idea recently to auto-generate GUIs for command line tools from the manpage syntax line, but it turned out that while such lines look precise but cryptic, they are often in fact highly ambiguous, nonstandard, and still cryptic. Thi…

Linux kernel tools solves this, but the help looks cryptic and is difficult to parse by a human(such as myself).

I can't find documentation on what I mean, but try ip --help

Post reply on HN