So, i was given a task to implement simple version of cat utility. It should support some of GNU keys, for given text returns the same results as real cat utility and i was given this synopsis:

cat [OPTION] [FILE]...

What i want to know can my utility be called with multiple keys or just with one?

cat -b file

or

cat -b -s -e file

[POSIX](https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/)(in BaseDefinions, chapter 12) says: > The notation used for the **SYNOPSIS** sections **imposes requirements on the implementors of the standard utilities** and provides a simple reference for the application developer or system user. And it the same chapter [POSIX](https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/) says: > Ellipses ( "..." ) are used to denote that **one or more** occurrences of an operand **are allowed**. --- So if **OPTION** can be repeated, why there is no ellipsis after it in synopsis? For example, there is an ellipsis [man7.org](https://man7.org/linux/man-pages/man1/cat.1.html) :

-plaintext
cat [OPTION]... [FILE]...

but not [gnu.org](https://www.gnu.org/software/coreutils/manual/html_node/cat-invocation.html)( but this cat allows many options):

-plaintext
cat [option] [file]...

Can someone explain should my program work with many keys at a time and why? And why [gnu.org](https://www.gnu.org/software/coreutils/manual/html_node/cat-invocation.html) doesn't follow this(ellipsis) utility syntax convetion?

Am I being a curmudgeon, or should /etc/default be reserved to settings for the operating system? I'm seeing systems show up with /etc/default/{company}-environment. The file is typically Tomcat data, but not always. I've also seen setup data for Mqueue. One objection I've heard that makes sense on a technical level is that it does not allow applications to migrate to Containers. Beyond that, am I just carping? I posted this question over in ServerFault, but it isn't getting any answers. What does the group assembled here think? I've looked in the local Confluence docs and it's been this way for like ten years. The technical curmudgeon in me just objects because /etc should not have anything but operating system components. I'd be interested in others' thoughts.

I'd like to place a handmade script in its conventional place and folder structure. It's currently located in /opt/chkobm/chkobm, but it seems like a bad practice since it requires $PATH to include wildcard paths (/opt/*/) From TLDP (section "Linux Filesystem Hierarchy"): > Programs to be invoked by users are located in the directory /opt/'package'/bin. Firstly, is there a consensual rule about where to place such files ? (/usr/bin looks to me like a viable alternative place) Secondly, should I place handmade scripts to /opt/*/bin/ and export this path to $PATH ?

To me, the name of the feh image viewer is not memorable enough for me to recall it when I need it. I feel that if I had some context, I'd be able to remember it better. **What, if anything, does the name "feh" stand for?**

I'm creating a CLI utility which is aimed at *nix OS:es. Let's call it 'Super CLI Project'. Looking at the latest POSIX Issue 7, 2018 edition - https://pubs.opengroup.org/onlinepubs/9699919799/ - Utility Conventions - The section shows an example with underscores like this -> utility_name[-a]... which I could interpret as that my util should be named super_cli_project, by convention (with underscores as separator). However, POSIX does not say this explicitly. A quick 'ls' in my /usr/bin/ shows that most utils in my OS (Ubuntu) that consists of several words uses a hyphen instead of an underscore. That implies that my util should be named 'super-cli-project' instead. So, what is really the preferred naming convention here? Note: There are a few discussions regarding FILENAMES in general for this topic - but not for the naming conventions of *nix CLI utils themselves.

I know there is a syscall convention but what do you call the calling convention that precedes it that you see when you call to int 80 rather than syscall, like this. mov rax,4 ; system call number (sys_write) mov rbx,1 ; file descriptor (stdout) mov rcx,hello ; message to write mov rdx,12 ; message length int 0x80 ; call kernel I read [here](http://www.int80h.org/bsdasm/#system-calls) that the arguments after rdx are esi, edi, ebp (or for x64 rsi, rdi, rbp), I don't see it documented in [Wikipedia's page for calling conventions](https://en.wikipedia.org/wiki/X86_calling_conventions) , but [int80h](http://www.int80h.org/bsdasm/#system-calls) seems to indicate that Windows also uses this convention? What is this conventioned named. Where in the Linux Kernel source can I see it defined? And, where is the table that resolves rax to the procedures when you call int 0x80? For syscall, sys_write is rax=1

Is it bad practice to have a dot file and an adjacent identically named file without dot? --- Background: We already create a $HOME/.ourapp directory where we store various configuration files, log files, etc. but we are debating where to put files that the user would add, create, and modify, either from outside the app or from within it, using various tools. It would seem most natural have these in $HOME/ourapp but that might be bad practice or confusing.

On my Ubuntu jammy Linux PC, after installing the libuv1 package (apt-get install libuv1), I noticed that there was a file, named libuv.so.1.0.0 and a symbolic link to it, named libuv.so.1:

$ find /usr -name "libuv.so*" 2>/dev/null
/usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
/usr/lib/x86_64-linux-gnu/libuv.so.1
$ ls -l /usr/lib/x86_64-linux-gnu/libuv.so*
lrwxrwxrwx 1 root root     14 Jan 15  2022 /usr/lib/x86_64-linux-gnu/libuv.so.1 -> libuv.so.1.0.0
-rw-r--r-- 1 root root 198744 Jan 15  2022 /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
$

From probably incomplete understandings, I was expecting there to also be a libuv.so symbolic link, something like /usr/lib/x86_64-linux-gnu/libuv.so -> libuv.so.1. I've seen this mix of presence/absence of the .so symlink, but never properly understood if there was a reason/convention behind that. I thought I might have stumbled into The Answer in this blog post . If I correctly understand the content of that post: - semantic-versioned .so files, e.g. libfoo.so.1.0.0 are the real files that symlinks ultimately resolve to; they are compiled with the soname option, e.g. gcc -I . foo.c -shared -Wl,-soname=libfoo.so.1 -o libfoo.so.1.0.0. - Because of the use of the soname option, when a binary is compiled with -lfoo (in an environment where there exists libfoo.so -> libfoo.so.1 -> libfoo.so.1.0.0 links), the compiler/linker will look for libfoo.so, which resolves to libfoo.so.1.0.0, which has been compiled with -soname=libfoo.so.1, therefore the binary will know that it needs libfoo.so.1 at runtime. (i.e. readelf -d on the binary would output something like 0x0000000000000001 (NEEDED) Shared library: [libfoo.so.1]) - When the binary is run in an environment with only libfoo.so.1 -> libfoo.so.1.0.0 (i.e no libfoo.so -> libfoo.so.1), it will run fine: because of the above, it will be looking for libfoo.so.1, not libfoo.so. *My conjecture*: this seems to imply that only when you are _developing_ with a shared library will you need the libfoo.so symlink because of the need to specify the -l flag, e.g. g++ use-foo.cpp -o ./use-foo -lfoo. In this case, the use of -lfoo means the compiler/linker will be looking for libfoo.so, not libfoo.so.*. The above seems to bear out with compiling a simple hello-world example that links dynamically, and also inspecting what is installed with the libuv1 vs. libuv1-dev packages:

$ apt-file list libuv1 | grep so.*
libuv1: /usr/lib/x86_64-linux-gnu/libuv.so.1
libuv1: /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
$
$ apt-file list libuv1-dev | grep so.*
libuv1-dev: /usr/lib/x86_64-linux-gnu/libuv.so
$

But then a wrench was thrown into the works, when I found files, _not symlinks_, like libmemusage.so (I'm just picking one example, at random):

$ ls -l /usr/lib/x86_64-linux-gnu/libmemusage.so
-rw-r--r-- 1 root root 18904 Sep 25 07:45 /usr/lib/x86_64-linux-gnu/libmemusage.so

My question is: **is there one comprehensive rule that describes the relationship between libfoo.so, libfoo.so.x, and libfoo.so.x.y.z, when and why any specific combination of them should exist, and when and why any of them should be files vs. symbolic links?** Is there any case where I, as a non-developer Linux PC user, am supposed to create any "missing" symbolic link (as in the very beginning of the question, where I saw libuv.so.1 but not libuv.so)? (Context to this question: in the past, I've been asked to create a "missing" libfoo.so symlink, when libfoo.so.x and/or libfoo.so.x.y.z existed, but I never properly understood why this was necessary, other than a half-baked notion that "there's always a bunch of .so files, and they seem to have "corresponding" .so.x and .so.x.y.z files). --- (I can see the case that this question might belong at Stack Overflow: it's tangentially related to programming, but I ultimately thought that the heart of the question was about Unix/Linux conventions. But please let me know if it's certain that this question is better suited for Stack Overflow.)

Is there any reason why aliases like

alias rm='rm -i'

found in the ~/.bashrc file of user root are not used by default for any other users?

A good and well-established guideline for commenting a shell function is to put it before the function's header . I am trying to follow these guidelines as much as I can, but this convention makes it hard to read the function's comments. For instance, I don't have access to the comments of my function

#######################################
# init the current directory with the required files to work with latex in Vscode's extension LaTeX workshop
# Arguments:
# $1 -> Main .tex file. Optional. Default to "main.tex"
#######################################
initlatex () {
	curl https://gist.githubusercontent.com/tapyu/886dc95fc19c4250fb38581ccc58bed8/raw/0eeaa62d401659fe1c57602ec8f17608775d5338/_default_preamble.tex  > default_preamble.tex
	grep -q "\\input{default_preamble.tex}" ${1:-main.tex} || sed -i '2i\\\input{default_preamble.tex}\n' ${1:-main.tex}
	curl https://gist.githubusercontent.com/tapyu/886dc95fc19c4250fb38581ccc58bed8/raw/Makefile  > Makefile
	[[ ! -d .vscode ]] && mkdir --parents --verbose .vscode
	curl https://gist.githubusercontent.com/tapyu/886dc95fc19c4250fb38581ccc58bed8/raw/0eeaa62d401659fe1c57602ec8f17608775d5338/_vscode_makefile.json  > .vscode/settings.json
}

directly on terminal by using the which command:

❯ which initlatex
initlatex () {
	curl https://gist.githubusercontent.com/tapyu/886dc95fc19c4250fb38581ccc58bed8/raw/0eeaa62d401659fe1c57602ec8f17608775d5338/_default_preamble.tex  > default_preamble.tex
	grep -q "\\input{default_preamble.tex}" ${1:-main.tex} || sed -i '2i\\\input{default_preamble.tex}\n' ${1:-main.tex}
	curl https://gist.githubusercontent.com/tapyu/886dc95fc19c4250fb38581ccc58bed8/raw/Makefile  > Makefile
	[[ ! -d .vscode ]] && mkdir --parents --verbose --parents --verbose .vscode
	curl https://gist.githubusercontent.com/tapyu/886dc95fc19c4250fb38581ccc58bed8/raw/0eeaa62d401659fe1c57602ec8f17608775d5338/_vscode_makefile.json  > .vscode/settings.json
}

Is there another command to print out the function's comments without breaking this best practice?

A couple of weeks ago I attended a talk on Git by someone who seemed to be from a Windows background. I say "seemed to be" because he kept saying "dash" when referring to command-line options. I then recalled something that I found curious in my early days of learning Linux; that is, when referring to options, the resident Unix-heads always said "minus". That is: rm -rf /var/tmp/bogus/junk Would be said "arr em minus arr ef" as opposed to "arr em dash arr ef". Why is this?

By convention, stdout is -. Is there something similar for stderr?

I am looking for best practices, or at least conventions, for the PATH variable's value. In particular, I would like to know 1. is there any preferred/recommended ordering for the /bin, /usr/bin, and /usr/local/bin directories in the value of PATH? 2. are there any downsides to including /sbin, /usr/sbin, and/or /usr/local/sbin in a non-root user's PATH variable? Regarding (1), my uninformed opinion is that these paths should appear in the order ..:/usr/local/bin:...:/usr/bin:...:/bin:... ...in the PATH variable. The thinking here (to the extent there is any) is that /usr/local/bin may be where a local installation would put a "local" override of a command that may also exist under /usr/bin. By the same token (and now really stretching it!), /usr/bin may contain distro-/vendor-level overrides to commands that traditionally live under /bin. I realize that the above is 99% fantasy. That's why I am asking this question. In a similarly hallucinatory vein, I seem to recall the notion that the commands in */sbin directories are meant for folks with superuser privileges, and it would confuse the regular users' little brains to make these commands available to them. In other words, the PATH variable for regular users should not include any */sbin paths. Be that as it may, I don't recall ever coming across a system that included */sbin paths in the initial setting of the PATH variable (by this I mean the setting of PATH that each user gets before his/her shell initialization scripts are run), and I wonder why this is so.

So, I am currently writing some scripts to gather and bulk report break-in attempts on my server. The scripts itself are working, but I am wondering where I should put my config files and the script itself. I thought about making an installer that would copy the required binaries in `/usr/local/bin` but for the configuration file I am not sure. I have had this problem in the past when I was installing for example `automysqlbackup, some program that will automate running and tidying up mysql backups. Do I create a new directory in /etc with a name of my choosing or is /var/lib` the place for additions that do not come from packages? What is the conventional place to store these configuration files? Should I keep the shell scripts and binaries and configuration files together in one place thats completely different?

Other than a short dalliance with Arch, my linux experience has been with Debian/Ubuntu based distros, so maybe that answers my question... I know I can rename /home/$USER/Download to anything I want, but it seems odd as every other folder is lowercase. ...just wondering

For udev device entries, what is the technical difference between a "property" and an "attribute"? How are they customarily created (generated?) and used? Which one is the better source of truth? I'm asking in the context of a Raspberrypi Python application that should detect any hot-plugged serial port adapters and display the "relevant" device information (whatever that is) to the user, to enable them recognise their devices. In particular, I use [the pyudev library](https://pyudev.readthedocs.io/en/latest/) to interface with libudev, and my plan is to search for devices from the tty subsystem that are provided by a usb-serial subsystem device. I've looked through the properties and attributes by some test devices I had lying around, to see what values they provide and where. So far, they all have in common that there is a subsystem: tty->(subsystem: usb-serial->)subsystem: usb, device_type: usb_interface->subsystem: usb, device_type: usb_device device ancestor chain (below the USB hub) that relates to the adapter, and the values like vendor, model and serial number are duplicated in various properties and attributes all over the four devices (or sometimes three, [ACM* tty devices](https://rfc1149.net/blog/2013/03/05/what-is-the-difference-between-devttyusbx-and-devttyacmx/) have no usb-serial). So which one should I access? Is there any (written) convention which attributes/properties such devices bring with them, and where can I find it? I've read (or at least skimmed over) [various](https://wiki.archlinux.org/title/udev) [documentation](https://wiki.debian.org/udev) [pages](https://opensource.com/article/18/11/udev) , but they mostly describe how to write your own udev rules, which is not what I'm after. I understood from the udev manual ([](https://linux.die.net/man/7/udev) , [](https://www.freedesktop.org/software/systemd/man/udev.html)) that ATTR is used for values stored in sysfs attributes of the device, and ENV is used for "device properties", but both can be matched and also written. I suppose there are some default rules that inherit values from a parent device to a child device, but that's happening for both properties and attributes alike? [This answer](https://unix.stackexchange.com/a/598900/190272) says "*If both ENV and ATTR contain the same information - you can use any of them, there is no any difference.*", which doesn't leave me any wiser.

The man page for tar in Arch Linux **SYNOPSIS** section starts with: tar {A|c|d|r|t|u|x}[GnSkUWOmpsMBiajJzZhPlRvwo] [ARG...] I perfectly understand that in this situation it means that exactly one of the options in the curly braces must be given because it says so further down in the man page. Is there some kind of standard or convention on using {} around a list of mutually exclusive options? All I can find is a User's group tutorial on man from 1998 where it says: > Some options will have a limited list of choices. A list of choices > will be comma separated and put between braces. > > {choice1,choice2} > {yes,no} Seems like every convention (like this one from the Open Group ) or man page describes only square brackets ([]) or vertical lines (|).

While I was reading the document of some Linux utilities, I found that they always quote strings using ` and '. For example, below is an excerpt from the man page of the **find** utility.

-exec command {} +
              This variant of the -exec action runs the specified
              command on the selected files, but the command line is
              built by appending each selected file name at the end; the
              total number of invocations of the command will be much
              less than the number of matched files.  The command line
              is built in much the same way that xargs builds its
              command lines.  Only one instance of `{}' is allowed
              within the command, and it must appear at the end,
              immediately before the `+'; it needs to be escaped (with a
              `\') or quoted to protect it from interpretation by the
              shell.  The command is executed in the starting directory.
              If any invocation with the `+' form returns a non-zero
              value as exit status, then find returns a non-zero exit
              status.  If find encounters an error, this can sometimes
              cause an immediate exit, so some pending commands may not
              be run at all.  For this reason -exec my-
              command ... {} + -quit may not result in my-command
              actually being run.  This variant of -exec always returns
              true.

As you can see, there are several such cases like \{}', \\\' and \`+'. Why they don't use a pair of single quotes or backtick?

WSL with Ubuntu 18.04 and GNU bash, version 4.4.20(1)-release (x86_64-pc). I wish to display a message with a *conventionally named color* via argument such as -red, or -green, or -blue or anything like this (**Without an end user required to define colors with machine syntax**). I don't think that even the modern versions of printf or echo can do that. I'd prefer a shell-builtin and not installing anything.

I know that, by default, bash will source /etc/profile and ~/.bash_profile. Now, suppose I also have machine-specific profile commands in /usr/local/etc/profile (involving stuff that's in /usr/local, hence I don't want to sully /etc with it). My question: Whose responsibility is it to source /usr/local/etc/profile ? Should it be sourced within ~/.bash_profile, or perhaps the lines:

if [ -f /usr/local/etc/profile ]; then
    . /usr/local/etc/profile
fi

_should_ actually be within /etc/profile, since they're valid for any installation of the distribution regardless of what's on the actual machine?