What does "-g" option mean in sort command? - sorting

Could someone explain me what g means in this unix command?

I like using explainshell.com for these kinds of questions. Which says;
-r, --reverse
reverse the result of comparisons
-g, --general-numeric-sort
compare according to general numerical value

Related

How Bash parse multi-flag commands?

I'm trying to create an overly simplified version of bash, I've tried split the program into "lexer + expander, parser, executor".
In the lexer i store my data (commands, flags, files) and create tokens out of them , my procedure is simply to loop through given input char by char and use a state machine to handle states, states are either a special character, an alphanumeric character or space.
Now when i'm at an alphanumeric state i'm at a command, the way i know where the next flag is when i encounter again alphanumeric state or if input[i] == '-', now the problem is with multi-flag commands.
For example:
$ ls -la | grep "*.c"
I successfully get the command ls, grep and the flag -la, *.c.
However with multi-flag commands like.
$ sed -i "*.bak" "s/a/b/g" file1 file2
It seems to me very difficult, and i can't figure out yet, how can i know where the flags to a specific command ends, so my question is how bash parse these multi-flags commands ? any suggestions regarding my problem, would be appreciated !
The shell does not attempt to parse command arguments; that's the responsibility of the utility. The range of possible command argument syntaxes, both in use and potentially useful, is far too great to attempt that.
On Unix-like systems, the shell identifies individual arguments from the command line, mostly by splitting at whitespace but also taking into account the use of quotes and a variety of other transformations, such as "glob expansion". It then makes a vector of these arguments ("argv") and passes the vector to execve, which hands them to the newly created process.
On Windows systems, the shell doesn't even do that. It just hands over the command-line as a string, and leaves it to the command-line tool to do everything. (In order to provide a modicum of compatibility, there's an intermediate layer which is called by the application initialization code, which eventually calls main(). This does some basic argument-splitting, although its quoting algorithm is quite a bit simplified from that used by a Unix shell.)
No command-line shell that I know of attempts to identify command-line flags. And neither should you.
For a bit of extracurricular reading, here's the description of shell parsing from the Posix standard: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html. Trying to implement all that goes far beyond the requirements given to you for this assignment, and I'm certainly not recommending that you do that. But it might still be interesting, and understanding it will help you immensely if you start using a shell.
Alternatively, you could try reading the Bash manual, which might be easier to understand. Note that Bash implements a lot of extensions to the Posix standard.

Is it possible to write a bash script that changes the current directory to a random one?

Of course there would be little to no point to this, but the idea struck me today and I haven't really seen anything on it. I suppose it could be a good exercise on efficiency, especially if you consider every directory under (/).
First idea that comes to mind:
Pipe a recursive ls command to a file, use wc to count number of lines, then generate a random integer and use it to pick a line from the file you just created.
ls -R / >> file_list.txt
count=$(wc -l file_list.txt)
etc. You can get it from here.

How to sort list of jobs by submitted time/job name?

In LAVA or LSF, how to sort the output of bjobs command by submitted time/job name?
Bare bjobs usually gives a mess. I cannot find the right option in manuals, e.g., in this one.
There isn't an option to sort bjobs' output by time or job name. You could manually parse the specific column.
Depending on what information you are interested in... you can look into bjobs -r, -p, -u flags.

What does & do at the end of a wc command?

I am learning the bash environment and cannot understand what I get when running this command:
wc filename.txt &
It returns an array with a 1-digital integer and another integer, neither of them matches any other result I can get from wc commands (-l, -m, -w, -c).
Besides the second integer is much bigger than for example the bytes counts. So I terribly wonder.
I browsed forums and found some explanations on the multiple uses of the ampersand in a Unix/Linux environment, but there was nothing that I could relate.
I don't need it, but I won't flush this mystery away, I wish to understand!
Thanks
I imagine the integers you see are similar to this:
[1] 1830
& launches a command in the background, and the shell prints its job number (1) and process id (1830). On a longer-running job, you can use those two numbers to control its execution. See the JOB CONTROL section of the bash man page for more details.
An ampersand at the end of a WC command tells the shell to start executing the command in the background and to get ready for further command line commands.

User friendly command line options

I know boost::program_options from c++ which enables me to write user- friendly command-line options in almost no time. With "user- friendly" I mean, short and long options and a descriptive help command which would look similar to this:
Copy standard input to each FILE, and also to standard output.
-a, --append append to the given FILEs, do not overwrite
-i, --ignore-interrupts ignore interrupt signals
--help display this help and exit
--version output version information and exit
For myself I had to find out that this is really awkward in bash with the built-in getopts only supporting short options. Is this correct or am I wrong?
How would you implement user friendly command line options? If you know any links, best practices or in depths tutorials I would be really much appreciated.
GNU getopt supports long options and can be used from any Bourne-like or csh-like shell. ksh93's builtin getopts supports long options as well. zsh has a zparseopts.
There's a POSIX shell implementation of getopts (as a shell function) that supports long options at http://stchaz.free.fr/getopts_long.sh
Thank you for pointing me to the correct sources of information.
I decided to do it this way https://github.com/Mythli/tech/blob/master/bash/getopt.sh
The code is pretty straightforward so no explanation should be needed.

Resources