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

81–90 of 131 posts

Re: Hints for writing Unix tools

#81

Post by ygra »

lstamour wrote: post #78
tfigment wrote: post #30

Earlier quoted context omitted.

Not sure if its what you had in mind for Windows and tabs but I've found ConsoleZ [1] quite nice and allows powershell, cmd and others to have tabs. [1] https://github.com/cbucher/console

Yeah, I know it's possible with adding, I've tried Console2 and ConEmu before. But I'd like it to just work out of the box with no extra software, as it does on Mac or Linux. Until Windows 10, that terminal hadn't changed since NT days...

You can use the PowerShell ISE. Which has tabs and you can just hide the script pane to get only the console itself. Startup time is a bit hefty, but if you have tabs you probably create new tabs way more often than the tab container.

Especially for PowerShell the whole problem that Console2, etc. have is trivial, as you have an API to create a host application instead of relying on polling a hidden console window. The console host is just one of those hosts.

Re: Hints for writing Unix tools

#82

Post by grymoire1 »

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 hate it when a program has a huge --help output, and the man page is nearly empty, and says "see the --help option for more details." Things like examples, see also, etc. are very valuable to someone trying to figure out how to use a program....

Re: Hints for writing Unix tools

#83

Post by emmelaich »

dap wrote: post #27
jzwinck wrote: post #12

Here's one more tip: did you ever notice that "ls" displays multiple columns, but "ls | cat" prints only one filename per line? Or how "ps -f" truncates long lines instead of wrapping, while "ps -f | cat" lets the long lines live? You can do it too, and if you're serious about writing Unix-style filter programs, you will someday need to. How do you know which format to write? Call "isatty(STDOUT_FILENO)" in C or C++,…

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.)

And yet .. programs are not just for composition. They have to behave sensibly for people.

I love that 'git log' outputs in a pager. 'svn log' by comparison is nuts.

Re: Hints for writing Unix tools

#84

Post by aidos »

emmelaich wrote: post #83
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.)

And yet .. programs are not just for composition. They have to behave sensibly for people. I love that 'git log' outputs in a pager. 'svn log' by comparison is nuts.

That's an interesting case. Should it not just output to stdout and you have to pipe it to less? If you wanted it to always pipe to less you could just set up an alias for it.

Re: Hints for writing Unix tools

#85

Post by philh »

chriswarbo wrote: post #75
philh wrote: post #73

Earlier quoted context omitted.

Are you suggesting that colored prompts violate the rules of consistency and least surprise? (Actually, if you are suggesting that, I'm not going to disagree. But I am going to say that if so, those rules don't apply in the case of colored prompts, because colored prompts are useful .)

I suppose I'm suggesting that, aside from personal scripts, we shouldn't assume too much about who our users are and what they're trying to do. The principle of least power tells us to use the dumbest format that will work, eg. plain text. Anything we add on top of that, eg. ANSI colour codes, will be useful to some but harmful to others. The tricky part is working out which of those categories the current user is in…

So is your proposed solution not to have colored prompts? (I vehemently disagree.) Or not to put them in a .bashrc? (I still disagree, but only strongly.) Or something else?

Re: Hints for writing Unix tools

#86

Post by renox »

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?

YMMV but I prefer cleaning the old tempfiles at start-up. It allows you to get the content of the tempfiles after the program stopped, very handy for debugging..

Re: Hints for writing Unix tools

#87

Post by simpleigh »

mjevans wrote: post #64
to3m wrote: post #61

Earlier quoted context omitted.

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.

Only the other week I managed to mouse-twitch into existence a file that rm refused to remove.

Re: Hints for writing Unix tools

#88

Post by emodendroket »

dec0dedab0de wrote: post #72
ygra wrote: post #53

Earlier quoted context omitted.

I was also constantly thinking of PowerShell while reading that. A PowerShell-specific list of such advice would actually be rather short, given that most of the pitfalls are already avoided. I still firmly believe that PowerShell is actually a much more consistent Unix shell in that several concepts that ought to be separate are actually orthogonal. Let's see: Input from stdin, output to stdout: Nicely side-stepped…

I have never used a computer that had access to Powershell, but in my new job I may have to do some small stuff to tie some systems together. I'm terrified of learning it because I don't want to be lured into some kind of lock-in scenario.

Well, you can only use it on Windows. But I mean come on, "terrified?" Bash scripts are not too useful in Windows either.

Re: Hints for writing Unix tools

#89

Post by kec »

aidos wrote: post #84
emmelaich wrote: post #83

Earlier quoted context omitted.

And yet .. programs are not just for composition. They have to behave sensibly for people. I love that 'git log' outputs in a pager. 'svn log' by comparison is nuts.

That's an interesting case. Should it not just output to stdout and you have to pipe it to less? If you wanted it to always pipe to less you could just set up an alias for it.

The git diff and log commands are primarily intended for human consumption. I'm not the one you were relying to, but I think it makes sense that git defaults to make that consumption easier, even if it isn't strictly "Unix". (You can also disable this behavior and get a more Unix-y interface by default via gitconfig or on a case by case basis with --no-pager).

Re: Hints for writing Unix tools

#90

Post by pjc50 »

aidos wrote: post #84
emmelaich wrote: post #83

Earlier quoted context omitted.

And yet .. programs are not just for composition. They have to behave sensibly for people. I love that 'git log' outputs in a pager. 'svn log' by comparison is nuts.

That's an interesting case. Should it not just output to stdout and you have to pipe it to less? If you wanted it to always pipe to less you could just set up an alias for it.

I've just realised that the best solution to this (which I've never seen) is for the shell or terminal emulator to capture long output into a pager for you once it exceeds a certain length.
Post reply on HN