Once, I've learned that options of Linux commands came in two manners:  those of one letter, prefixed by a - those of many letters, prefixed by a --  And this works in 95% of the cases. But not, for example, for the find command. This one fails: find . --name myfilename  And this one is working: find . -name myfilename  Either I'm wrong with my belief that options start by - or -- depending on their number of letters, Either find command should, I agree, retain for compatibility it's ability to run with the -name option, but it should also accept the --name option. What's the truth ?
123006
On Unix system, options begin with - is short option, while options begin with -- is long option. Is my understanding right?
10337
Why do we use ./filename to execute a file in linux?  Why not just enter it like other commands gcc, ls etc...
47349
Sometimes when I simply type a valid command like 'find ...', or anything really, I get back the following, which is completely unexpected and confusing (... is command name I type): sh: $'\302\211...': command not found  There is some corruption going on I think. I don't use color in my prompt, I am using the Bash shell in POSIX mode as sh (chsh to /bin/sh and so on - $SHELL is sh). What is going on and why does this keep happening? Anything I can debug? I think this is more of an xterm issue than sh, or at least a combination of the two. Files, for context: My /etc/profile, as distributed with Arch Linux x86-64: # /etc/profile  #Set our umask umask 022  # Set our default path PATH=&quot;/usr/local/sbin:/usr/local/bin:/usr/bin&quot; export PATH  # Load profiles from /etc/profile.d if test -d /etc/profile.d/; then         for profile in /etc/profile.d/*.sh; do                 test -r &quot;$profile&quot; &amp;&amp; . &quot;$profile&quot;         done         unset profile fi  # Source global bash config if test &quot;$PS1&quot; &amp;&amp; test &quot;$BASH&quot; &amp;&amp; test -r /etc/bash.bashrc; then         . /etc/bash.bashrc fi  # Termcap is outdated, old, and crusty, kill it. unset TERMCAP  # Man is much better than us at figuring this out unset MANPATH  My /etc/shrc follows below. It's something I created as a way to have sh parse some file on startup, for a non-login shell; it is achieved using ENV variable set in /etc/environment with the line ENV=/etc/shrc: PS1='\u@\H \w \$ ' alias ls='ls -F --color' alias grep='grep -i --color' [ -f ~/.shrc ] &amp;&amp; . ~/.shrc  My ~/.profile, I am launching X when logging in through first virtual tty: [[ -z $DISPLAY &amp;&amp; $XDG_VTNR -eq 1 ]] &amp;&amp; exec xinit -- -dpi 111  My ~/.xinitc, as you can see I am using the system as a Virtual Box guest: xrdb -merge ~/.Xresources  VBoxClient-all  awesome &amp;  exec xterm  And finally, my ~/.Xresources, no fancy stuff here I guess: *faceName: Inconsolata *faceSize: 10 xterm*VT100*translations: #override &lt;Btn1Up&gt;: select-end(PRIMARY, CLIPBOARD, CUT_BUFFER0)  xterm*colorBDMode: true xterm*colorBD: #ff8000 xterm*cursorColor: S_red  Since ~/.profile references among other things /etc/bash.bashrc, here is its content: # # /etc/bash.bashrc #  # If not running interactively, don't do anything [[ $- != *i* ]] &amp;&amp; return  PS1='[\u@\h \W]\$ ' PS2='&gt; ' PS3='&gt; ' PS4='+ '  case ${TERM} in   xterm*|rxvt*|Eterm|aterm|kterm|gnome*)     PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf &quot;\033]0;%s@%s:%s\007&quot; &quot;${USER}&quot; &quot;${HOSTNAME%%.*}&quot; &quot;${PWD/#$HOME/~}&quot;'                                                              ;;   screen)     PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf &quot;\033_%s@%s:%s\033\\&quot; &quot;${USER}&quot; &quot;${HOSTNAME%%.*}&quot; &quot;${PWD/#$HOME/~}&quot;'     ;; esac  [ -r /usr/share/bash-completion/bash_completion   ] &amp;&amp; . /usr/share/bash-completion/bash_completion  I have no idea what that case statement does, by the way, it does look a bit suspicious though, but then again, who am I to know.
16320
When I'm using  find . -type f -name "*.htm*" -o -name "*.js*" -o -name "*.txt"  it finds all the types of file. But when I add -exec at the end:  find . -type f -name "*.htm*" -o -name "*.js*" -o -name "*.txt" -exec sh -c 'echo "$0"' {} \;  it seems it only prints .txt files. What am I doing wrong?  Note: using MINGW (Git Bash)
119579
When you enter an invalid command at a bash prompt you get the message  -bash: {command}: command not found   What does the - at the very beginning signify?
40960
I read many questions and answers like  and   I know wildcards are expanded by the shell before running a command and they are a feature of the shell.  Also wildcards work with those commands that can accept many arguments.  In find . -name *.rb  if we have more than one file in the current directory find will give us an error because find cannot accept multiple arguments and the ways to solve this are:  find . -name "*.rb" find . -name '*.rb' find . -name \*.rb   We escape the asterisk and prevent expansion by the shell but wildcards are a feature of the shell; when we escape the asterisk shell does not know about its meaning, and it should find a file named *.rb, so how is the asterisk being expanded in this case?
74228
Possible Duplicate:          Most commands I use in linux behave exactly the same whether I include the trailing slash / character on the end of a directory name or not.  For example:  ls /home/cklein ls /home/cklein/  cp foo bar cp foo/ bar/   When does this trailing slash matter?  What is the semantic meaning of the trailing slash?
77169
Sometimes I see a command like  find . -name * -exec ls -a {} \;   I was asked to execute this.  What does {} \; mean here?
39072
I'm trying to merge the output of 2 find commands and pipe it to the next operator. The arguments passed to both find executions are very similar so I'd like to keep it DRY  FIND_CMD_ARGS="-type f \( -iname \*.m -o -iname \*.swift \) -print0" CMD_OUTPUT=`{ find $PROJECT_PATH -not -path '*/Pods/*' $FIND_CMD_ARGS; find . -path '*/Pods/MyProject*/*' $FIND_CMD_ARGS }`   For some reason this doesn't work and this is the output I get  find: illegal option -- n usage: find [-H | -L | -P] [-EXdsx] [-f path] path ... [expression]        find [-H | -L | -P] [-EXdsx] -f path [path ...] [expression] find: -type f \( -iname \*.m -o -iname \*.swift \) -print0: unknown primary or operator   I think the issue is related to how the args in the FIND_CMD_ARGS environment variable are escaped but I can't figure out the right way to do it.  Any ideas? Thanks!
29054
I understand that the -exec can take a + option to mimic the behaviour of xargs. Is there any situation where you'd prefer one form over the other?   I personally tend to prefer the first form, if only to avoid using a pipe. I figure surely the developers of find must've done the appropriate optimizations. Am I correct?
69994
See below example:  $ ls -1p appledir/ applefile orangedir/ orangefile $ find . -type f -name apple\* ./applefile $ find . -type f -name orange\* ./orangefile $ find . -type f -name apple\* -o -name orange\* ./applefile ./orangedir ./orangefile $ find . -type f \( -name apple\* -o -name orange\* \) ./applefile ./orangefile $    I was surprised to discover I needed the parentheses for this to work as expected; apparently I haven't internalized the rule of precedence by which find evaluates its arguments.  How can I easily predict when I will and when I will not need to use parentheses to explicitly group find primaries?  Put another way, what are the rules by which I can imagine find inserting parentheses into the commands I give it, which will allow me to accurately predict how it will evaluate ungrouped expressions?
24442
sudo find / -name "*" | xargs grep -sn --color=auto "-j"   Above command returns below:  grep: invalid option -- 'j' Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. ...   How do I search for string -j?
45542
When I enter single quote ' in terminal it goes to some other mode, and commands don't execute. What is this mode and when do we use it?  root@sai:~# ' &gt; ls &gt; ' ls : command not found root@sai:~#
96219
I was playing around in a shell and typed ./. I go the following output:  bash: ./: Is a directory   It looks like "./" checks if a directory with the given name exist. I was trying to find documentation on this to see if my understanding was right, but can't find anything online. Can anyone explain this one to me?
109570
I have a find command:  find Directory/{Alpha,Bravo,Charlie} arg1 arg2   I want to replace Alpha,Bravo,Charlie with $find_dir  find Directory/{$find_dir} arg1 arg2   however the latter expands to   find Directory/{Alpha,Bravo,Charlie} arg1 arg2   rather then   find Directory/Alpha Directory/Bravo Directory/Charlie arg1 arg2   Why? It's part of a fairly complex bash script that may have more or less directories, not all which are relevant (so globbing Upload/* would not work). So if I setup three now and add another, I'll have to manually add it in later. Plus I need it run from the root of directories to keep finds outputs perspective (./Upload/Dir/file as opposed to ./Dir/file).   But using a variable would permit me to change that as needed and keep it relevant to other parts of the script.
85969
In all shells I am aware of, rm [A-Z]* removes all files that start with an uppercase letter, but with bash this removes all files that start with a letter.  As this problem exists on Linux and Solaris with bash-3 and bash-4, it cannot be a bug caused by a buggy pattern matcher in libc or a miss-configured locale definition.  Is this strange and risky behavior intended or is this just a bug that exists unfixed since many years?
20796
I was wondering where I can find and learn some general idea about the command line interface used in Linux and bash? As to now, I have found pieces of such information only from experience, such as   For cat, without any further arguments, it accepts stdin input. But you may explicitly specify STDIN using the special name -, and both ways are equivalent. cat can also accept a filename as cat filename. So is - meant to fill in an argument supposed for filename? Is this usage of - also common for other commands? In chardet &lt;&lt;&lt;somestring, &lt;&lt;&lt; means a string  is used as stdin, the same as echo somestring | chardet. Is this usage of &lt;&lt;&lt; also common? In cut -c 1-3,20,25- employees, is the way 1-3,20,25- to specify a range of numbers for an argument also common in other commands?  Last but not least,  are these general ideas common to just within bash, or within Linux and Unix, or within software using getopt as command line parser?