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

211–220 of 222 posts

Re: Unix command line conventions over time

#211

Post by pjmlp »

tambourine_man wrote: post #208
pjmlp wrote: post #199

Earlier quoted context omitted.

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.

So now only if 100% of the features got migrated, does it count.

In any case this is playing guessing games, what would have happened if Apple wasn't begging for money.

So who knows how System 9, 10… would have turned out.

As for the Longhorn example, part of it did ship, as SQL Server features and some ideas on ReFS.

Re: Unix command line conventions over time

#212

Post by t43562 »

aleksiy123 wrote: post #209
t43562 wrote: post #204

Earlier quoted context omitted.

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.

I think you're right but I believe that wrapping it in List(...) is where that would force the whole file into memory.

Re: Unix command line conventions over time

#214

Post by euroderf »

Maursault wrote: post #180
euroderf wrote: post #131

Earlier quoted context omitted.

I come not to bury wheel, but to praise it.

An industry big wheel, a wheel man with nice wheels, put shoulder to the wheel to put wheels in motion spinning wheels to reinvent the wheel before the wheels came off the wagon and squeaky wheel gets the grease. My name is Jonas. I'm carrying the wheel.

I confess that back in the day, whenever I tried to grok a man page or manual page about wheel, it was basically incomprehensible.

Re: Unix command line conventions over time

#215

Post by aleksiy123 »

t43562 wrote: post #212
aleksiy123 wrote: post #209

Earlier quoted context omitted.

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.

I think you're right but I believe that wrapping it in List(...) is where that would force the whole file into memory.

Yeah, you're right, that's my mistake.

I think you can just omit it but yeah...

Re: Unix command line conventions over time

#216

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?

I found guidelines [1] that list several common short options:

  -a, --all
  -d, --debug
  -f, --force
  -h, --help
  -o, --output
  -p, --port
  -q, --quiet
  -u, --user
[1] https://clig.dev/#arguments-and-flags

Re: Unix command line conventions over time

#217

Post by conaclos »

kzrdude wrote: post #35
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

Thanks for teaching something useful!

Actually you can expand any pattern:

  --option{X,Y}   ->  --optionX --optionY
  --option:{X,Y}  ->  --option:X --option:Y
  ...

Re: Unix command line conventions over time

#218

Post by tambourine_man »

pjmlp wrote: post #210
tambourine_man wrote: post #207

Earlier quoted context omitted.

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.

I'm aware :)

I don't know how that proves that it's not a company willing to rewrite foundational/taken for granted stacks.

Re: Unix command line conventions over time

#219

Post by tambourine_man »

pjmlp wrote: post #211
tambourine_man wrote: post #208

Earlier quoted context omitted.

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.

So now only if 100% of the features got migrated, does it count. In any case this is playing guessing games, what would have happened if Apple wasn't begging for money. So who knows how System 9, 10… would have turned out. As for the Longhorn example, part of it did ship, as SQL Server features and some ideas on ReFS.

Sure, the whole point of the thread was a guessing game. I'm speculating that Apple, had it not been worried with going bankrupt, could have tried to fix code that had grown organically and incoherently over decades.

And that this was a missed opportunity for the whole industry as it's probably not going to happen anytime soon.

Re: Unix command line conventions over time

#220

Post by yencabulator »

mort96 wrote: post #89
frederikvs wrote: post #28

Earlier quoted context omitted.

I don't think remembering rm is the issue. It's remembering all the options in all their variations. Take the ps command. I tend to use it as "ps aux" - but I have no idea what the a, the u, or the x stand for individually. I know other people who use "ps -ef". (Also note the difference : the aux doesn't require a dash, and if you accidentally put it in, it doesn't do what you want it to do.) As another example : the…

My favorite example: `cp -r` is recursive. `scp -r` is recursive. `chmod -r` removes read permissions; `chmod -R` is recursive.

I ever use chmod without specifying at least one of ugoa. Helps with that mistake.
Post reply on HN