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

101–110 of 131 posts

Re: Hints for writing Unix tools

#101

Post by ygra »

emodendroket wrote: post #93
ygra wrote: post #81

Earlier quoted context omitted.

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. T…

I'm drawing a blank on the specifics but some things will work in the PowerShell prompt that won't work in the ISE.

Programs that want access to the actual console. E.g. for interactive input, moving the cursor around, etc.

Re: Hints for writing Unix tools

#102

Post by pessimizer »

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

I despise it when commands do this - mysql -e results are formatted differently depending on whether the output is directed to the terminal or to a file.

Re: Hints for writing Unix tools

#103

Post by pessimizer »

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.

Spending a lot of time learning non-portable technologies isn't a decision to be taken lightly.

Re: Hints for writing Unix tools

#104

Post by oblio »

bmn_ wrote: post #74
deathanatos wrote: post #23

Earlier quoted context omitted.

> 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…

I think dwheeler is trying to get this fixed/standardised in POSIX via the Open group.

That it's going to be an uphill battle is an understatement.

Someone replied on LWN, when he posted his proposal, that he had implemented a sort of home-grown database using non-UTF8 characters for the file names.

Rube Goldberg, indeed!

Re: Hints for writing Unix tools

#105

Post by emodendroket »

pessimizer wrote: post #103
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.

Spending a lot of time learning non-portable technologies isn't a decision to be taken lightly.

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

Re: Hints for writing Unix tools

#106

Post by pessimizer »

emodendroket wrote: post #105
pessimizer wrote: post #103

Earlier quoted context omitted.

Spending a lot of time learning non-portable technologies isn't a decision to be taken lightly.

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.

Re: Hints for writing Unix tools

#107

Post by philh »

wtbob wrote: post #95
philh wrote: post #85

Earlier quoted context omitted.

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?

Or, y'know, have coloured prompts but place the escape characters such that they don't mess with prompt-detection regexps.

To be precise, what you're suggesting is that we have prompts which are allowed to be colored except for the $/# at the end, because you can't color those without following them by escape characters. And that prompts must have a $/# at the end.

I don't consider that an acceptable solution.

Re: Hints for writing Unix tools

#108

Post by to3m »

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.

I can't decide if this is a rebuttal, or not ;) - assuming it is, note that the number of possible paths containing newlines OR spaces is smaller than the number of possible paths containing only newlines, so an xargs that didn't handle newlines by default would still be supporting more possible paths than it does in its current state!

Re: Hints for writing Unix tools

#109

Post by peterwwillis »

masklinn wrote: post #100
peterwwillis wrote: post #98

Earlier quoted context omitted.

I honestly have no idea what you are talking about. The whole point of standard i/o streams is for them to be portable and composable by other programs without those programs having to be designed to work with yours. POSIX is here for a very good reason. Obviously not every program will use just two file descriptors. Binary isn't handled by stdin and stdout because they're typically used for tty input/output. If you…

> I honestly have no idea what you are talking about. The whole point of standard i/o streams is for them to be portable and composable by other programs without those programs having to be designed to work with yours. His point is that two streams are not enough, you don't want to present the same output stream or a human, a logfile or an other utility. > And what 'formatting markup'? There is no 'markup' on a termi…

In practical terms, everything you mention should be done by different programs, not one giant monolithic subsystem that manages 10 completely different tasks. Each component should be reusable, independent, and interoperable. Not tied into one program.

In your program's design, the 'cat' program would handle all kinds of file i/o, provide some kind of ncurses text GUI to select a file, a progress bar for the progress of text flowing through it, sending errors to a logging subsystem, storing header metadata in some object passed along its output streams, etc. The Unix designers had dealt with this kind of crap before, and were sick of it, and so they wrote a program which did only one thing.

What you describe is the systemd school of design. If I just make my program more complex and technically superior, i'll have a better program. Who cares that nobody wants to use it, or that it's burdensome, hard to extend, difficult to understand, and incompatible with everything that exists today? Who cares if we can already do all these things without all the downsides? Technical superiority trumps practicality. Well, that's not Unix.

The Unix environment flourished not only because it was widely available, but mainly because it was incredibly efficient. By removing all the things they didn't need, they made the system better. There are four words that accurately express all of this, and that should guide the development of any Unix tool:

Keep it simple, stupid. https://people.apache.org/~fhanik/kiss.html

Re: Hints for writing Unix tools

#110

Post by burke »

ksherlock wrote: post #91
burke wrote: post #22

Earlier quoted context omitted.

Or, execute "/bin/[ -t 1" (or "test -t 1", or "[[ -t 1 ]]", or ...). This is handy in shellscripts (obviously), but also in languages like Go, which lack a builtin way to test whether stdout is a TTY. e.g.: cmd := exec.Command("/bin/[", "-t", "1") cmd.Stdout = os.Stdout isatty := nil == cmd.Run()

Please just call Fstat and check Stat_t.Mode & S_IFCHR

Wow, that's a lot easier than the OS-dependent Syscall6 crap with termios from the "real" solutions I've seen.
Post reply on HN