What's the pattern in terminal commands?

Question

Just starting to dive into the terminal thanks to the fun Raspberry Pi. I have one thing in particular that still has me scratching my head:

I'm noticing the different daemons / services / processes / applications / etc (anything else I'm leaving out?) that are also called differently.

This is kind of what I mean:

(program, filename)

nano mytextfile

(service, action, program)

service restart nginx

(action, program)

killall openvpn

It has basically been memorization exercises for me at this point and I don't comprehend the syntax yet. Is it anything something like this?:

"service" when it's a service, as opposed to...? >
action for program if applicable >
name of program >
additional parameters

Could someone please briefly explain the difference between these and the different ways to access them?

this is pretty broad. historically, there are some conventions that (some, not all) commandlines follow. if you look back far enough, even those boil down to 'the programmer thought doing it that way was a good idea'. there are very few firm rules here. — quixotic, Jan 24 '18 at 04:55
I am voting to close as Too broad as this question could be answered with literally hundreds of different answers. — Vlastimil Burián, Jan 24 '18 at 05:02
You would be better with experimentation and understanding it, than trying to memorize it. Pretty much like driving a car. — Rui F Ribeiro, Jan 24 '18 at 10:19

score 3 · Answer 1 · answered Jan 24 '18 at 05:41

Of the potential patterns you listed, this is the only one that actually exists:

name of program > additional parameters

First a few word definitions:

a program or an application: basically a file that can be executed
a process: an instance of a program that is currently running
a daemon: a program or process that is doing something independently of any user's login session; usually something that is or can be started automatically at boot time, and runs until the system is shut down; things like remote access protocol server (e.g. sshd), web server (Apache), network connections manager (NetworkManager, ModemManager)...
a service: something that is typically started at boot time; can be a daemon or just a script that sets up something and ends, and may do the corresponding tear-down actions when the system is being shut down. In some contexts, may also refer to the arrangement to make a program start at boot as a daemon.

service started its life as a simple wrapper for SysVinit-style startup/shutdown scripts. If traditional SysVinit is used as init system (the process #1, the "mother of all processes") in Linux, these scripts are typically located in /etc/init.d directory. Those scripts have standardized parameters: start for starting a service, stop for stopping one, or status for querying the state of a service. There are a few others.

But because writing /etc/init.d/<service name> <action parameter> was tedious, someone made a simple wrapper script: service <name> <action parameter> originally meant just /etc/init.d/<name> <action parameter>.

When SysVinit was replaced with more modern alternatives (systemd, upstart or others), people wanted to keep the familiar service command and made it a wrapper for the equivalent command for their init system. When systemd is used, service <name> <action parameter> is usually just a wrapper for systemctl <action parameter> <name>. Note the changed order of parameters.

score 1 · Answer 2 · answered Jan 24 '18 at 05:11

First in Unix the philosophy is that everything is a file. In all your commands, you are only dealing with files on your hard disk: mytextfile, nginx or openvpn are all files.

Now, what the files represent and what actions you can have on them is merely dictated by conventions. Sometimes, and coming from some other OS, files have extensions to better illustrate what they do. Like a text file you can edit will be with .txt at the end, a program will be .sh or .php or .pl, etc. But there are only conventions (the unix bit x for execute is another hint at what is data versus what is executable)

What you list are actions (nano, service restart, killall) on different objects/files (mytextfile, nginx, openvpn).

Depending on the action you choose and the objects the results would be different. You could as well have done nano openvpn and it would edit, or create, a file called openvpn where you are (this would probably be useless and disturbing, but the tools do not forbid that).

Now as for your specific actions:

nano is a text editor, to modify the content of any file (of course if it is a binary files - like some executables but not all - it would be the wrong tool to use to do anything useful)
service restart is an action with a "subaction" of restart that uses the current framework on your system dealing with starting/stopping long lived processes also called daemons; note that it is only one case among others, it could have been /etc/init.d/nginx restart elsewhere or systemctl restart nginx.service; the fact that restart exists as a subaction is entirely specific to the service command; any command can have different syntax, with different switches, arguments, subactions, etc. Noone can memorize them all.
and killall is a command to look at the list of all current running processes and kill the ones matching the given name (bit of warning: this command does not do the same things on all Unix systems so make sure to read its manual on the host you are using it before using it), so you could in fact provide any name and not necessarily something that exist as a file on disk

Many of your terms are synonyms and loosely defined anyway. An application is anything that can run (be executed), when it is running it is a process handled by the kernel among many other processes. Long living applications typically not under direct control of the user, such as network applications like a webserver, were often called daemons in the past, and are today often called services (even more with systemctl see example syntax above)

You should not have to memorize any kind of this stuff. You will learn it by using them, like if you work with nginx as web server, you will need to restart it and in your specific platform for that it is service restart and so on.

+1 for You should not have to memorize any kind of this stuff. — Vlastimil Burián, Jan 24 '18 at 06:33
`killall` doesn't deal with files. And saying that `service` deals with (just) files is quite a simplification, since it also deals with processes, and there's a lot of rather important logic on top of those files. — ilkkachu, Jan 24 '18 at 08:51
@ilkkachu You are restating what I already wrote: "...so you could in fact provide any name and not necessarily something that exist as a file on disk" and I never stated that `service` just deals with files. And yes the whole response is a simplification since the question was overly broad. However I wanted to take the opportunity to pass the unix philosophy of everything is a file. — Patrick Mevzek, Jan 24 '18 at 14:30
@PatrickMevzek, No, I'm saying that the statement in your first paragraph is totally false: "In all your commands, you are only dealing with files on your hard disk: mytextfile, nginx or openvpn are all files.". `killall` doesn't deal with files. If you run `killall openvpn` it will not touch any file called `openvpn`. It will touch a process. Not a file. — ilkkachu, Jan 24 '18 at 14:35
@ilkkachu Please read all my answer, not just the first paragraph. Maybe I oversimplified but the message was that `openvpn` is typically a file somewhere on the disk, which happens to be an executable, and a daemon, hence a process, and hence you need this name for the `killall` command to act on it. I did not say that the command acts on files I say that the arguments passed are/could be filenames plus the sentence later on saying that you can pass other things to `killall` (I know what `killall` does, thanks, see my warning in fact). — Patrick Mevzek, Jan 24 '18 at 14:54

score 1 · Answer 3 · answered Jan 24 '18 at 06:07

Although there are standard conventions such as:

There is nothing really keeping a developer from breaking convention for whatever reason and using whatever syntax they want. So really it just depends on the application you're using at the time.

Generally you'll find the GNU standard linked above to be very common, and will notice over time that a lot of commands use similar arguments for similar things (e.g.: -v for printing a verbose output)

Don't worry about memorizing any of this. For the applications you use regularly, you will eventually pick up the syntax and it will eventually become second nature. For applications you are unfamiliar with, there are always man pages, or the --help flag.

Having a general knowledge of what essential commands do, and being able to open and quickly parse a man page is infinitely more important than memorizing the flags for each command.

Kusalananda · Accepted Answer · 2018-01-24T10:43:53.610

The "pattern" is given by the shell's grammar. In simple cases, it's a command (or rather, a utility), followed by arguments. Arguments may be options, and options may have option arguments. After the options there may be other operands.

Example:

ls -l dir

ls is the command, -l is an option (with no option argument), and dir is an operand. We know that dir is not an option argument to the -l option since we have read the ls manual in which the synopsis section describes the calling sequence of the utility.

Example:

git commit -p

git is the command and since there are no options immediately following the command name, the rest is treated as operands. It's up to the git command to interpret this. You may want to call the commit operand a "sub command" if you wish, and -p an "option" to this sub command.

Example:

cc -o code.o -Wall code.c

Here, cc is the command and both -o and -Wall are options. The -o option takes code.o as an option argument. Depending on the cc command, the -Wall option may in fact be parsed as -W all, i.e. as an option with an option argument (one-letter options do not require a space before their option arguments). code.c is an operand as it occurs after all options.

The words "argument", "option" and "option argument" are the ones used by the POSIX standard. The standard uses the word "utility" rather than "command" as a command may be simple, a list, compound, pipeline etc. For example, ls -l dir is one (simple) command using the utility ls, and { head -n 20 | tail -n 5; } >file is a compound command containing a pipeline and two simple commands.

Arguably, all utility invocations are "actions". Saying killall myprog means "start the utility killall with the operand myprog". The effect thereof will be that the utility, in this case, sends a signal to a process.

Likewise, service restart nginx is the action of invoking the service utility with restart and nginx as the two operands. The effect thereof will be that the nginx service is restarted.

Likewise, nano somedoc is the action of invoking the nano editor, etc. etc.

What's the pattern in terminal commands?

4 Answers4