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

191–200 of 222 posts

Re: Unix command line conventions over time

#191

Post by jlarocco »

msla wrote: post #163
jlarocco wrote: post #136

Earlier quoted context omitted.

> What would the non-shell interface to commands for text processing pipelining (e.g. sort, cut, grep, etc., all of which absolutely need options to function) have looked like? Some people to this day believe that any text processing more complicated than a simple grep or cut should be done in a stand-alone script written in a domain-specific language (e.g. Perl or awk), rather than piping shell commands to each othe…

The problem there is that you have to rethink your solution if you decide you want to turn your buffer manipulation into a reusable command. I like Emacs, but the easy transition from pipeline to shell script is a big point in pipelines' favor.

It's not really a problem, though. 9 times out of 10 shell one-liners are single use, and when they're not, I want something more readable than a one liner, anyway.

Re: Unix command line conventions over time

#192

Post by qsdf38100 »

StringyBob wrote: post #80
JadeNB wrote: post #71

Earlier quoted context omitted.

> tar is a bit messy but the worst is definitely the worst. It has dash and non-dash options, and they don't have the same meaning and interact in a weird way. Sorry if it should be obvious, but "the worst is definitely the worst" … what is the worst? (Presumably not tar, unless I'm reading incorrectly.)

ps. By far the worst. Because it supports multiple syntax types I can never remember the ps command options. Even if you google for examples you get different syntax and end up with a mix of the same option letters doing different things in one command. It seems to lead to all sorts of subtly unexpected behaviors

ps afx

I like the forest (tree) mode.

Re: Unix command line conventions over time

#193

Post by AlphaSite »

bfrankline wrote: post #74

I was at Bell during the options “debate.” I think something that this otherwise wonderful article misses is that some believed that commands were never intended to be the only way to use the system as the shell was intended to be just one of the many user interfaces that Research Unix would provide. From that perspective, it was entirely reasonable to believe that if a command was so complex that it needed options t…

I imagine powershell could do this quite well with it’s typed output.

(Not that you can’t just base raw bytes via unix shells but it’s awfully error prone).

Re: Unix command line conventions over time

#194

Post by mek6800d2 »

MontyCarloHall wrote: post #81
bfrankline wrote: post #74

I was at Bell during the options “debate.” I think something that this otherwise wonderful article misses is that some believed that commands were never intended to be the only way to use the system as the shell was intended to be just one of the many user interfaces that Research Unix would provide. From that perspective, it was entirely reasonable to believe that if a command was so complex that it needed options t…

>From that perspective, it was entirely reasonable to believe that if a command was so complex that it needed options than it was likely more appropriate for one of the other user interfaces What would the non-shell interface to commands for text processing pipelining (e.g. sort, cut, grep, etc., all of which absolutely need options to function) have looked like? Some people to this day believe that any text processi…

I haven't looked at this in years, but IIRC Knuth's program could be built and run on almost any OS that had a Pascal (?) compiler, whereas McIlroy's solution obviously required a Unix-like shell, piping, and the necessary commands/tools.

Re: Unix command line conventions over time

#195

Post by michaelcampbell »

chubot wrote: post #118
protomikron wrote: post #66

Interesting is also find. It took me some time to accept that the directory must come first. E.g. find /path/to/dir -type f works, while find -type f /path/to/dir does not.

I wrote a post about how to understand find syntax: find and test: How To Read And Write Them https://www.oilshell.org/blog/2021/04/find-test.html tl;dr The args AFTER the root dir args form a boolean expression language -- I call it the "I'm too lazy to write a lexer" pattern find /tmp -type -f -a -name 'foo*' test is the same way, e.g. test -f /tmp -a -f /bin

    find /tmp -type f -a -name 'foo*'  # no "-" for the -type
this is bitten me more often than I'd care to admit.

Re: Unix command line conventions over time

#196

Post by dredmorbius »

butlerm wrote: post #130
dredmorbius wrote: post #31

Earlier quoted context omitted.

dd is a mainframe command, and its syntax follows the JCL conventions used there. https://www.ibm.com/docs/en/zos-basic-skills?topic=concepts-...

The name of dd(1) may have some tenuous connection to the JCL DD statement, but otherwise any similarity seems virtually non-existent. They don't even remotely do the same thing, none of the options or parameters are the same or have similar meanings, or anything like that. https://man7.org/linux/man-pages/man1/dd.1.html

I'd ... thought that more of the Unix arguments (block, unblock, conv, etc.) were supported on JCL, though my IBM link doesn't support that.

I'll see if I can find a more canonical / complete reference.

Re: Unix command line conventions over time

#197

Post by 1vuio0pswjnm7 »

Macha wrote: post #189
1vuio0pswjnm7 wrote: post #175

Earlier quoted context omitted.

OpenBSD, which is a fork of NetBSD, is not the only "outlier".^1 For many years, NetBSD tar has autodetected bzip2 compression. tar xzf 1.tar.bz2 will work on gzip as well as bzip2. Whereas GNU tar still requires "j" instead^2 tar xjf 1.tar.bz2 1. For example, FreeBSD or MacOS tar is BSD tar. It will autodetect bzip2 compression. 2. The GNU tar included with VoidLinux still requires z or j. The pax(1) utility is the…

Void Linux appears to include GNU tar 1.34 The following should work, it worked on my Arch Linux install (but note that auto detection is not a "new" feature to GNU tar, I've been using it for at least 5 years) echo "Hello" > foo.txt tar cjf foo.tar.bz2 foo.txt rm foo.txt tar xf foo.tar.bz2 cat foo.txt and produce "Hello" To be clear, I'm not saying the following should work tar xzf foo.tar.bz2 What should work is: t…

If I have a script I want to work on both BSD and Linux, and I do want to rely on uname, I usually do something like

   bzip2 -dc 1.tar.bz2|tar xf -

Re: Unix command line conventions over time

#198

Post by chubot »

michaelcampbell wrote: post #195
chubot wrote: post #118

Earlier quoted context omitted.

I wrote a post about how to understand find syntax: find and test: How To Read And Write Them https://www.oilshell.org/blog/2021/04/find-test.html tl;dr The args AFTER the root dir args form a boolean expression language -- I call it the "I'm too lazy to write a lexer" pattern find /tmp -type -f -a -name 'foo*' test is the same way, e.g. test -f /tmp -a -f /bin

find /tmp -type f -a -name 'foo*' # no "-" for the -type this is bitten me more often than I'd care to admit.

Oops, good point! Gah

I honestly wonder where this wonky syntax came from ... i.e. was it a Bell Labs thing or later

Re: Unix command line conventions over time

#199

Post by pjmlp »

tambourine_man wrote: post #183
pjmlp wrote: post #109

Earlier quoted context omitted.

In that case, there wouldn't be any desktop UNIX from Apple, and Copland would have managed to eventually make it.

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 premise that Apple wouldn't be bleeding money, they would been able to keep up with their roadmap with System 8 and integration of Copland technologies.

Re: Unix command line conventions over time

#200

Post by dredmorbius »

elvis70 wrote: post #85
dredmorbius wrote: post #31

Earlier quoted context omitted.

dd is a mainframe command, and its syntax follows the JCL conventions used there. https://www.ibm.com/docs/en/zos-basic-skills?topic=concepts-...

The parameter names don't seem to match those of dd. If you type man dd, the function of the tool will be described as "copy and convert". I can't find the video but there is an interview in which Kernighan, I think, explains that the tool should have been named cc but it was not possible because it was already taken by the c compiler.

The IBM webpage only covers a few of the JCL DD parameters.

There are more at pp. 486ff in Doug Lowe, MVS JCL (1994) here:

http://library.lol/main/6784CBC9EE9BBA5AD26993F497514661

It's still a rather rough fit, though I'm still pretty sure the connection exists.

Keep in mind that Unix dd dates to the early 1970s, and JCL itself may have evolved.

Post reply on HN