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

Unix command line conventions over time

blog.liw.fi

Post reply on HN
Print view View original

201–210 of 222 posts

Re: Unix command line conventions over time

#201

Post by pjmlp »

tambourine_man wrote: post #184
tambourine_man wrote: post #95

If Apple made the transition to OS X in a position of strength, like the one it enjoys today, I think it may had imposed a pattern and rewritten tar, ps, dd, etc. However, the way history has unfolded, I think we’re stuck with this mess for good.

If there ever was a company that could've tried “Unix done right™” was Apple. Maybe Sun. But I guess it wasn't meant for this world. Perhaps Apple's biggest contribution to the Unix/Linux landscape was launchd, which inspired systemd. I don't know if we would've endeavored in rewriting essential and mostly working decades-old parts if there wasn't a proven path already laid out. Maybe LLVM as well, a modular compiler…

AIX and Solaris already had init replacements before launchd.

Sun's only good idea for desktop UNIX was NeWS and they killed it. Their desktop execution for Swing proves how much they understood (not really), desktop development.

As for Apple and UNIX, it was more the inverted takeover from NeXT than anything else, given A/UX execution.

Also Steve Jobs wasn't a UNIX fan, it was more of a embrace POSIX due to the competition with Sun, and extend with NeXTSTEP Objective-C frameworks than anything else.

Get hold of his USENIX talk about "UNIX should be invisible".

Re: Unix command line conventions over time

#202

Post by kzrdude »

conaclos wrote: post #38
jolmg wrote: post #33

Earlier quoted context omitted.

It also has the advantage that it works with brace expansion to specify multiple values. --long={foo,bar} becomes --long=foo --long=bar

With bash/zsh the auto-completion seems missing for unknown options. While `--key file` supports auto-completion since file is just another parameter.

that's a tool issue that should be fixed

Re: Unix command line conventions over time

#203

Post by conaclos »

kickingvegas wrote: post #170

With this thread, wondering what specs/guidelines (if any) are there for common option behavior? For example, -v, —-version -o , —-output= if is - then use stdout -i , —-input= . if is - then use stdin -h, —-help Or is it just anarchy out here?

-v is also used for --verbose. In this case -V is often used for --version.

Another common option I am thinking about is -r for --recursive.

I could advocate to use only commonly accepted short options.

Re: Unix command line conventions over time

#204

Post by t43562 »

aleksiy123 wrote: post #186
MontyCarloHall wrote: post #138

Earlier quoted context omitted.

How is it a misconception? My overall point was that shell oneliners are often much faster to quickly bang out for a one-off use case than writing a full program from the ground up to accomplish the same thing. This is demonstrated to a very exaggerated degree in the Knuth vs. McIlroy example, but it also holds true for non-exaggerated real-world use cases. (I had a coworker who was totally shell illiterate and would…

Seems like you should just go with what you you know best. Taking 10x longer doesn't seem like a language problem. If you don't know bash well you're going to take even longer to do it in bash than in python. In any case the task you described is pretty much the same in python as in bash. At worst the python is going to be more more verbose. python -c "print(len(set(w for l in list(open('test.txt')) for w in l.split(…

The shell's advantage is that of the pipeline components don't need to suck the whole file in so it can potentially operate on much larger files without running out of memory. I think only "sort" is problematic and at least it's a merge sort.

In Python you could use a generator but it would get a little more complicated and you'd still have to add all the words to set() but hopefully the number of different words is not that great.

The trie approach is quite memory efficient and that can matter.

Re: Unix command line conventions over time

#205

Post by thyrsus »

andi999 wrote: post #160
MontyCarloHall wrote: post #146

Earlier quoted context omitted.

Hah, I have a friend who spent a large chunk of an undergraduate summer internship at Google porting a >50k line bash script (that was used in production!) to Python. It was not their most favorite summer, to say the least.

How does one do that? I mean you just can type 50k lines in 2.5 month if you type 1000 lines per day. Which sound a lot to me.

It's only possible if you can identify large portions of the 50k original lines as having been previously implemented by other components (python modules, microservices, etc.), or that large portions are dealing with cases that are guaranteed to no longer arise (so you either produce different results or error out if you detect them).

Re: Unix command line conventions over time

#206

Post by jolmg »

jolmg wrote: post #140
mort96 wrote: post #88

Earlier quoted context omitted.

I find it really confusing when `+x` is used to mean the opposite of `-x`. Usually, the `-x` option means "enable something", which is fine when you think of the "-" as a dash, but introducing `+x` encourages you to think of them as minus and plus; suddenly, in your command's language, "minus x" means "enable x" and "plus x" means "disable x", which makes very little sense. The set command is a great example, "minus…

Yeah, but beyond that, I can't see any disadvantage to it. It's practical, relatively intuitive syntax. + isn't conventionally used for anything else, being partly conventional for this already, and it works to combine multiple options into one. The fact that they seem backwards seems like something that's easy to get used to over time. It's like electrons being negatively charged.

> Usually, the `-x` option means "enable something", which is fine when you think of the "-" as a dash, but introducing `+x` encourages you to think of them as minus and plus;

To get used to it, one could think of it as a crossed-out dash instead of a plus. Crossed-out means that the dash is disabled.

Re: Unix command line conventions over time

#207

Post by tambourine_man »

pjmlp wrote: post #201
tambourine_man wrote: post #184

Earlier quoted context omitted.

If there ever was a company that could've tried “Unix done right™” was Apple. Maybe Sun. But I guess it wasn't meant for this world. Perhaps Apple's biggest contribution to the Unix/Linux landscape was launchd, which inspired systemd. I don't know if we would've endeavored in rewriting essential and mostly working decades-old parts if there wasn't a proven path already laid out. Maybe LLVM as well, a modular compiler…

AIX and Solaris already had init replacements before launchd. Sun's only good idea for desktop UNIX was NeWS and they killed it. Their desktop execution for Swing proves how much they understood (not really), desktop development. As for Apple and UNIX, it was more the inverted takeover from NeXT than anything else, given A/UX execution. Also Steve Jobs wasn't a UNIX fan, it was more of a embrace POSIX due to the comp…

I wasn't trying to say that Apple (or Steve) is particularly found of Unix historicaly. Nor should they, Unix should be a means to an end, not one in itself. Unix should really be invisible to most users if present at all.

What I'm saying that Apple is a company usually willing to rewrite things the “right way”, vide Webkit, LLVM.

Re: Unix command line conventions over time

#208

Post by tambourine_man »

pjmlp wrote: post #199
tambourine_man wrote: post #183

Earlier quoted context omitted.

I don't know about that. I mean, look at Longhorn. And Microsoft was unbeatable back then. Being huge and powerful is no guarantee of success when it comes to shipping software. Size can often be a hinderance.

Exactly because Microsoft was unbeatable, Longhorn UI ideas survived as WPF, while the OS components were rescued into C++ and COM, clunky as Windows Vista, and refined into Windows 7, including a kernel rewrite via the MinWin project. They are on a similar position nowadays, trying to fix the UWP disaster, maybe by a future Windows 12 we get what Windows 8 should have been all along. Likewise, starting from the same…

Copland UI ideas and code survived and shipped in Mac OS 8. Multithreaded Finder, Platinum Theme (multiple themes in fact, though killed at the last moment), windows as tabs at the bottom of the screen.

However the main challenge, memory protection, didn't. Much like Longhorn's file system.

Re: Unix command line conventions over time

#209

Post by aleksiy123 »

t43562 wrote: post #204
aleksiy123 wrote: post #186

Earlier quoted context omitted.

Seems like you should just go with what you you know best. Taking 10x longer doesn't seem like a language problem. If you don't know bash well you're going to take even longer to do it in bash than in python. In any case the task you described is pretty much the same in python as in bash. At worst the python is going to be more more verbose. python -c "print(len(set(w for l in list(open('test.txt')) for w in l.split(…

The shell's advantage is that of the pipeline components don't need to suck the whole file in so it can potentially operate on much larger files without running out of memory. I think only "sort" is problematic and at least it's a merge sort. In Python you could use a generator but it would get a little more complicated and you'd still have to add all the words to set() but hopefully the number of different words is…

I'm fairly sure `open` is a generator and doesn't load the whole file into memory. So you wouldn't hit a memory error unless like you said the amount of unique words is high enough.

Re: Unix command line conventions over time

#210

Post by pjmlp »

tambourine_man wrote: post #207
pjmlp wrote: post #201

Earlier quoted context omitted.

AIX and Solaris already had init replacements before launchd. Sun's only good idea for desktop UNIX was NeWS and they killed it. Their desktop execution for Swing proves how much they understood (not really), desktop development. As for Apple and UNIX, it was more the inverted takeover from NeXT than anything else, given A/UX execution. Also Steve Jobs wasn't a UNIX fan, it was more of a embrace POSIX due to the comp…

I wasn't trying to say that Apple (or Steve) is particularly found of Unix historicaly. Nor should they, Unix should be a means to an end, not one in itself. Unix should really be invisible to most users if present at all. What I'm saying that Apple is a company usually willing to rewrite things the “right way”, vide Webkit, LLVM.

LLVM wasn't started by Apple, rather Illinois university, and they only adopted it after GPL 3 happened.

WebKit was born as Khtml by KDE project.

Post reply on HN