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

111–120 of 131 posts

Re: Hints for writing Unix tools

#111

Post by mzs »

edwintorok wrote: post #62
userbinator wrote: post #43

Earlier quoted context omitted.

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?

-w

Re: Hints for writing Unix tools

#112

Post by GhotiFish »

emodendroket wrote: post #88
dec0dedab0de wrote: post #72

Earlier quoted context omitted.

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.

cygwin does it's job well.

Re: Hints for writing Unix tools

#113

Post by gknoy »

chriswarbo wrote: post #63
burke wrote: post #28

Earlier quoted context omitted.

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…

As much as I love Emacs, that sounds like it's a bug to assume that one's prompt will follow a convention (ends-in-$). The convention is useful and good, but it seems strange to blame someone for breaking your tool's expectations when they had made a valid prompt.

Re: Hints for writing Unix tools

#114

Post by GhotiFish »

pessimizer wrote: post #106
emodendroket wrote: post #105

Earlier quoted context omitted.

Well, if it's part of your job I'd say it's not a decision at all...

If you can't accomplish the same goals in a portable way. Of course, if you can put the knowledge to work as soon as you learn it, you're already starting to recoup your investment.

I can't believe you got downvoted for that.

Re: Hints for writing Unix tools

#115

Post by emodendroket »

GhotiFish wrote: post #112
emodendroket wrote: post #88

Earlier quoted context omitted.

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

cygwin does it's job well.

cygwin works fine but if your task is, for instance, to configure Windows machines, it's not very useful.

Re: Hints for writing Unix tools

#116

Post by typedweb »

userbinator wrote: post #17
pstuart wrote: post #15

Earlier quoted context omitted.

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

Pathological or not, ensuring that pathnames can essentially contain any byte value except the 0 terminator, and it will still work, is important to prevent surprising behaviour which often has security implications.

The only character not allowed in Unix file names is the forward slash directory separator, so even that would be a pathological mistake waiting to bite someone.

Edit: my mistake, they can't contain nulls either: https://news.ycombinator.com/item?id=8485861

Re: Hints for writing Unix tools

#117

Post by tieTYT »

teddyh wrote: post #49
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.)

Indeed, the GNU Coding Standards explicitly argues against doing that: “ please don’t make the behavior of a command-line program depend on the type of output device it gets as standard output or standard input. ”¹ ① https://www.gnu.org/prep/standards/standards.html#User-Inter...

Interesting. Doesn't git (a pretty new tool) violate this? I think running log from the terminal pauses per page of output but if you pipe it to something it pipes all the content.

Re: Hints for writing Unix tools

#118

Post by stsp »

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.

I like the default pager in 'git log', too.

Some work has been done on the svn side: http://svn.apache.org/repos/asf/subversion/branches/automati...

However, it's not on trunk yet because it's hard to find good defaults. An automatic pager makes sense for some commands, but not all -- and in a meritocratic development model this kind of thing can cause an endless discussion... I suspect we'll eventually merge the feature in a disabled by default state and allow users to enable it on a per-command basis.

Git's hard-coding of options passed to the pager has problems, too: https://mail-archives.apache.org/mod_mbox/subversion-dev/201...

Re: Hints for writing Unix tools

#119

Post by 1amzave »

_pmf_ wrote: post #51

I have a strong bias against people who quote their own tweets in their own blog posts. I find this to be highly narcissistic.

I sympathize, but I have to say I find it far less annoying than the constant implorings to "follow me on Twitter!" that have become obnoxiously ubiquitous in the last few years.

Re: Hints for writing Unix tools

#120

Post by dkuntz2 »

tieTYT wrote: post #117
teddyh wrote: post #49

Earlier quoted context omitted.

Indeed, the GNU Coding Standards explicitly argues against doing that: “ please don’t make the behavior of a command-line program depend on the type of output device it gets as standard output or standard input. ”¹ ① https://www.gnu.org/prep/standards/standards.html#User-Inter...

Interesting. Doesn't git (a pretty new tool) violate this? I think running log from the terminal pauses per page of output but if you pipe it to something it pipes all the content.

I think it's just piping it to another program. It's still giving you the same output, but sending you to a program meant for humans to be able to read text in a console, instead of just printing it all out.

That said, I'm not entirely sure which git pipes to.

Post reply on HN