Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I found both git --version and git version are okay. They will show me the same output. However, if I try some other command, say, ls -l and ls l, only the first works.
I'd like to know how the arguments work in command line. When and where the dash or double dash before flag/arguments are necessary? Or I might be wrong with some concept when using the shell.
Thanks!
This is command dependent. There are some common commands like git or tar who have optional dashes. Most do not. You really have to read the man page to see what the command expects.
There are basically two styles for providing arguments on the command line.
The GNU style is characterized by characterized by options that look like this (-v) or like this (--verbose). The single dash sets of "short" options and the double-dash sets off "long" options. Not every short option will have a corresponding long option, or vice-versa. This syntax permits short options that do not take option arguments to be combined (for example, ls -al is equivalent to ls -a -l).
In the BSD style, one can have an option that looks like this: java -version where -version a single option, which may or may not take an argument. This style has evolved into one where complex commands have many subcommands, typically referred to as "verbs." This style is used by Apple in OSX, for example launchctl unload /path/to/some.plist ("unload" is the verb).
Hopefully this information will help you read the documentation as you go. You can find the options, and what they do, for any command, by executing, for example man ls. Note that, in some cases, there is more than one manpage for a given name. In this case, you can provide the section of the manual in which you would like to do the look up, eg man 1 crontab to see how to use the program that edits users crontabs, and man 5 crontab to see the format of an entry in these tables.
Understanding these families is useful. The authors of these commands do not want to reimplement option parsing, so they use one of the common libraries for performing this task. Thus, if you encounter a new command, once you know what family it falls into, you will have an easier time understanding the manpage.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I have just noticed that commands:
ps -T
and
ps T
give different results. For instance:
I mean lines 2 and 3 of second output.
Could someone please explain what happens here and how the dash really works in such commands (to be honest I thought options that didn't require an argument could be given without a dash).
Thanks in advance.
what happens here
From man ps with ps from procps:
This version of ps accepts several kinds of options:
1 UNIX options, which may be grouped and must be preceded by a
dash.
2. BSD options, which may be grouped and must not be used
with a dash.
3. GNU long options, which are preceded by two
dashes.
T Select all processes associated with this terminal.
-T Show threads, possibly with SPID column.
Two options with different meaning.
how the dash really works in such commands
Dash represents literally itself. - is a -, the character -. Then the program has logic, if the string that represents the argument passed to the program starts with a - character, then the logic of that program is different, then when the argument does not start with -.
o be honest I thought options that didn't require an argument could be given without a dash
Each and every program has it's own unique semantics and parsing. While there are conventions and standards and options starting with a leading - are the (almost) universal standard, there are exceptions. (For example, "traditional" tar command syntax recognizes options without a -.)
How to use dash (-) with unix commands correctly?
Consult that "command" that you want to run, as it depends on that command how it parses it's arguments.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
Is there some way to use alias ./ = "..." or some other command for doing this?
This is in principle a function of the shell you're talking about. Your alias syntax resembles the syntax for the alias commands of Bash and the POSIX shell, so we'll start there. I'm having trouble seeing why a conforming POSIX shell would reject
alias ./=...
to define an alias for ./, but
bash 4.4 does not accept it ("bash: alias: `./': invalid alias name"). That may be a point of non-conformance, but it is of little import because
such an alias would not have the effect I imagine you're looking for / concerned about, because aliases are recognized only where they appear as a whole (shell) words. Thus, although alias substitution might, in principle, be applied to the ./ in the command ./ ls, an alias for ./ would not be relevant to the command ./ls.
For a complementary view, consider tcsh 6.20. This is a member of the csh family of shells, so not a POSIX shell, but this family also has an alias command, and this particular shell does allow you to alias ./. Example
$ tcsh
$ alias ./ echo
$ ./ foo
foo
But in this family, too, alias substitution is applied only to whole words:
$ ./foo
./foo: Command not found.
As for alternative approaches, the other potential way for someone to try to redefine a common command in a POSIX-ish shell such as Bash would be by defining a shell function with the same name. This is not an issue for words containing the / character, however, because function names cannot contain that character. (And shells in the csh family do not provide for functions.)
But if your concern is about the effect that your code may have if run on a compromised system, then there is ultimately no assurance to be had. A sufficiently deep system compromise could replace any or all of the installed shells with customized versions, could replace the standard ELF loader with a customized version (so that compiled programs aren't safe, either), and could even replace the kernel with a customized version.
Thus, if you do not trust the system then you need to provide a whole system of your own: a bootable image with a kernel and enough tools, chosen and vetted by you, to do what you want to do. This is akin to a rescue image: it could examine the host filesystems by mounting them, but it would not run any of the programs there. This also has the advantage of testability. You don't have to try to ensure that your code does the right thing in every environment, but rather only that it does the right thing in the environment you built for it.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
(EDIT)
I am creating a bash program that has many fully featured options as a networking program written in python. In my program, I am using the below command and it's specific output will be used as a variable.
I am looking for a command or method to display only specific terminal output of a command. For example if, in my script, I use the command:
iwconfig wlan0
Yet all I wish to see from this command is what mode in which wlan0 is set. (i.e. Master, Managed, Monitor, etc.)
I have looked and searched all over Google and Bash specific sites and cannot find a solution. I may be overlooking something.
The grep option you're looking for is -o, or --only-matching in its long form. It outputs only text that matches the search you gave it, and nothing else. For example:
iwconfig wlan0 | grep -o 'Mode:[^ ]*'
outputs Mode:Managed on my machine. The single quotes are necessary so that the shell won't try to interpret the [, ] and * characters (with double quotes, if you happened to have a file with precisely the wrong name in your current directory, the shell might wrongly expand your parameter to the name of that file). The regular expression inside the single quotes means "the text Mode:, followed by any number of non-space characters", which is exactly what you were looking for.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I recently switched from Linux to OSX. I use console heavily, and previously I was able to do things like
ls ./dir -sgh
cp ./file ./dir -Rf
and so on. If I missed an option, it was enough to press up and just add it. OSX forces me to put options before arguments, like this:
ls -sgh ./dir
cp -Rf ./file ./dir
This behavior is frustrating, it is easy to forget about an option and you have to navigate to the beggining of a line just to add it. It is also hard to add another option if you forget about one.
Is there an easy way to fix this behavior and make it work the linux way? I guess it involves replacing default programs like ls with some counterparts.
OS X's userland is a mash of BSD, (outdated) GNU, and Apple utilities.
If want your utilities to behave like their Linux counterparts, you should probably install the entire GNU coreutils suite with something like
Homebrew.
Once Homebrew is installed, just use it to install the coreutils:
$ brew install coreutils
Edit: I didn't have to update my $PATH personally, but YMMV.
If your shell isn't finding the Homebrew-installed coreutils, make sure /usr/local/bin (or your custom path, if Homebrew was configured as such) is before /usr/bin and /bin on $PATH.
In the best-case scenario, all programs dynamically link the system libc and use getopt to process their arguments. getopt only looks at arguments until it finds the first non-option argument, then stops. You cannot change this behavior of getopt. You would have to replace the system libc with one having a different implementation of getopt.
However, there is no guaranteed that all programs load libc dynamically; some might link statically, in which case replacing the system libc would have no effect. Others may not even use getopt. In either case, the only option is to replace the program with one that behaves the way you want.
Option processing is not a feature of the shell. You'd need to patch the argument processing logic in each individual utility.
Alternatively, you could install e.g. the corresponding GNU utilities. They are not completely option-compatible with the default *BSD utilities, so you can't replace the system binaries; but you can arrange your PATH so that the locally installed versions are preferred for your personal use. Homebrew is popular for managing this.
In Bash, ctrl-A jumps to the beginning of line, and M-n jumps past the first token.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
Recently I play with an awesome programming language red. After I downloaded it on my Linux Box, and typed red --version, I got something unexpected:
$ red --version
GNU ed version 0.2
then I look up ed's manual, it's said it also named red, but don't explain why?
So does anyone know the secret history of ed's name, maybe it's a wonderful story. ;-)
Read GNU ed documentation, chapter on invoking ed. Running red is like running ed -r i.e. running it in ....
-r
--restricted
Run in restricted mode. This mode disables edition of files out of
the current directory and execution of shell commands.
BTW, bash (and several other utilities) have a restricted mode also, e.g. when invoked as rbash ....
And GNU ed manual says
A restricted version of ed, red, can only edit files in the current directory and cannot execute shell commands.
BTW, perhaps your red compiler got installed at some different path like /usr/local/bin/red. Try typing this (or some similar) path in full to invoke it. Learn about the role of PATH e.g. in environ(7) and execvp(3) etc... Perhaps edit your .bashrc to change your PATH or add a symlink from $HOME/bin/red to e.g. /usr/local/bin/red
The same happened to me a while ago, and it thought that Red had been packaged for my favourite Debian! Hélas, not.
I noted that the "red" executable belonging to ed package is /only a symlink to ed, at least on my debian:
# pierre#autan: ~ < 2013_10_13__12_16_23 >
ll /usr/bin/red
lrwxrwxrwx 1 root root 7 mai 12 19:10 /usr/bin/red -> /bin/ed
This leads to a point that I brought, a few months ago: I find that the name "Red" is a bit too general, and may be confusing. WHile googling "rebol" leads to many relevant matches, googling "red" leads to a tremendous amount of irrelevant stuff. However, as #DocKimbel (Red's author) pointed out, googling "red language" immediately leads to relevant URLs.
Now, what to do:
from Red's side: change "red" to another name, like red_lang ? so that ed and its red "alias" may still be used
from ed's side: get in the package and have it remove the red symlink. We should carefully check for dependencies.
Note that the first option is about programming: the future of Red, which is coming to life right now, depends on these kind of "details", and it concerns all programmers who will be coding in Red soon (plenty!;)).
The second option is not about programming at all: mea culpa.
As #HostileFork pointed out on https://chat.stackoverflow.com/rooms/291/rebol-and-red , ed is quite an old-fashioned tool: I suppose it must be still /only used by some scripts, and not that much by "normally-minded" human beings.
(I drifted a bit off-opic, didn't I? Sorry...)