Earlier quoted context omitted.
A shell is just how you interact with the underlying system. The gui is also a shell. Confusing I know!
I like to see it this way: A shell /wraps/ the kernel. You cannot issue system calls directly, but a program that handles user input generically (and ideally dynamically), can do this for you. A desktop environment, Emacs, and to an increasing degree web browsers are all different "shells".
Unix command line conventions over time
161–170 of 222 posts
Re: Unix command line conventions over time
#162Interesting 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.
Probably helps to think of find as its own weird pipeline rather than a command with options. The first element of the pipeline is the directory(/directories), then `-type f` filters out all the non-files, then `-name '*.txt'` filters out everything which doesn't end in ".txt", etc. That also helps to remember why `-maxdepth` has to be right after the directory; it affects which files even become part of the pipeline…
Re: Unix command line conventions over time
#163Earlier quoted context omitted.
>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…
> 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…
Re: Unix command line conventions over time
#164Earlier 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…
Also "nice".
> This is why the nice number is usually called niceness: a job with a high niceness is very kind to the users of your system (i.e., it runs at low priority), while a job with little niceness hogs the CPU. The term "niceness" is awkward, like the priority system itself. Unfortunately, it's the only term that is both accurate (nice numbers are used to compute the priorities but are not the priorities themselves) and avoids horrible circumlocutions ("increasing the priority means lowering the priority...").
Jerry Peek et al. in Unix Power Tools (O'Reilly, 2007, p. 507)
via https://stackoverflow.com/questions/14067128/why-are-nicenes...
Re: Unix command line conventions over time
#165Earlier quoted context omitted.
> that nobody can ever remember These have gone a long way for me: tar xzf eXtract Zipped File tar czf Create Zipped File Anything more complicated and I have to google.
The `-z` on extract is not needed on basically most modern tar implementations (OpenBSD's is I believe the one outlier). tar -xf foo.tar.gz (or .xz, .bz2, .zst, etc.) will work, auto detect the archive type and extract.
Re: Unix command line conventions over time
#166Earlier 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
//MYJOB JOB
//FOOBAR DD DSNAME=MYFILE,DISP=(,DELETE)
//STEP1 EXEC PGM=IEFBR14
IEFBR14 is a program that does nothing at all!Although the Unix dd command wasn't patterned on the JCL command, I suspect that the multiplicity of possible options led its designers to choose the key=value option syntax that looked vaguely OS/360ish.
By the way, the - flag for options first appeared in MIT's CTSS, which was the direct ancestor (at least at the user level) of Multics.
Re: Unix command line conventions over time
#167It's interesting, that no one questioned the use of double dash itself. It looks especially silly, when long options are used to encode some mini programming language (DSL), like in imagemagick and ffmpeg, or when they are used to represent some associative data, like in case of the AWS CLI. If -- would be a : AFTER the option name, it would look like Objective C named arguments or set-words in REBOL and Red. If -- w…
The double-dash is selected for pure practicality. Any option character excludes a set of inputs, and we want this set to be as small as possible. It is already hard to look at file named "-f" -- do you want to also make accessing files named ":f" (or even worse, "f:") harder? Thus the desire to keep the first "-". Now, they could have used "-:" or "-=" for long options.. but I think "--" won because it is so easy to…
rc and es is an good example of what improvements can be achieved, if we challenge historical decisions and get rid of the not so great ones.
The "; " prompt was just a historical side-note, because I saw someone asking about it the other day on twitter: https://twitter.com/thingskatedid/status/1316081075043463170...
By the quoting rules, I meant, that if you have a variable (eg v='a b') with a value containing whitespace, when you reference it ($v), then you don't have to worry about quoting it in any way, because the space in its value won't cause any problems.
Re: Unix command line conventions over time
#168There is this problem I face really often with that I semantically know all the small operation I want to run on command line but some of them have branching element in them. Often I just want to reconverge my data and run more commands. As one can imagine your writing in a functional way acting on raw data always but it's hard for other people to see a shell command or a bash script and really internalize the underlying operation.
It would be really fancy if you could take in a command line opt and generate a corresponding flow diagram too.
Re: Unix command line conventions over time
#169And then you have ImageMagick where the order of flags and options is a science by itself.
Re: Unix command line conventions over time
#170For 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?