Tag Info

You're in zsh, not bash. In zsh, repeat (inspired from csh repeat) is a construct used to repeat commands. repeat 10 echo foo Would echo foo 10 times. If you want to call your repeat, you'd need to quote it so that it's not taken as the repeat reserved word. $ echo $ZSH_VERSION 5.0.2 $ 'repeat'() echo "$*" $ type -a repeat repeat is a reserved word ...

They're completely different. Command-line arguments are passed to the program in an array and it can do what it wants with them; stdin is an input stream the program has to request data from. Programs that process files often choose to support both, but they have to do so manually -- they check if a filename was passed as a command-line argument, and if not ...

Since you're working in bash, use an array. excludes=() excludes+=('--exclude=/path/*') … tar -czf backup.tgz "${excludes[@]}" If you have an optional entry in some variable, add it in a conditional. if [[ -n $exclude_or_empty ]]; then excludes+=("$exclude_or_empty"); fi

tar -czf backup.tgz "$exclude1" "$exclude2" ${exclude3+"$exclude3"} 2>&1 ${exclude3+"$exclude3"} expands to nothing, if $exclude3 is unset, and to "$exclude3", if it is set. (and similarly for the other variables that are potentially unset.) Note that there is a difference between an unset variable and a variable that is set to the empty string, ...

This can be done using command substitution, like so: mvn -Dvar_name="$(cat /path/to/file)" # POSIX mvn -Dvar_name="$(</path/to/file)" # bash This has a notable caveat, though, namely that all trailing newlines are stripped. If that doesn't matter, though, then that should work. If you really just want to read one line, you could use read instead, ...

Your question is closely related of how the shell you are using parses user input on the command line. If the first word on the command line is a program, located in a special folder (mostly defined by PATH) and no more special characters are given (depends of the shell you are using), all subsequent words separated by spaces or tabs are passed to the ...

For command substitution, you need to use $() or backticks ``. It is also important that you quote the substitution, or it will expand into multiple arguments if the file contains more than one word. Here are some examples: mvn -Dvar_name="$(< /path/to/file)" # bash mvn -Dvar_name="$(cat /path/to/file)" # POSIX

In traditional Unix, options were one letter, like ls -l or ls -d. In some cases the option would take an argument, as in cut -d: -f1 /etc/passwd (-d (delimiter) with value :, -f (fields to select) with value 1). Where the options didn't take arguments, instead of ls -l -d -F /tmp/* you can write ls -ldF /tmp/*. Some commands take options starting with +, ...

I don't think that's true. The shell is the one interpreting the command line arguments and passing them to the corresponding commands as it (the shell) is parsing them. So your C program, when it finally get's executed will only see the arguments 1, 2, and 3. The pipe and everything after is the responsibility of the shell, and will not get passed in as ...

Pattern matching in POSIX shells is done with the case construct. ksh also as the [[ x = pattern ]] operator (also copied by bash and zsh) and [[ x =~ regexp ]] in recent versions. So: case $1 in (*5.0.3*) install=$1.tar echo Found;; (*) echo >&2 Not found exit 1;; esac

I assume you're actually typing ./myBashScript.sh < text.txt with a forward slash. When you run ./myBashScript.sh < text.txt, your interactive shell actually captures the < text.txt and interprets it as a special instruction – in particular, it interprets your command line to mean that it should run myBashScript.sh with standard input ...

Yes, it's the length in bytes, including the environment. Very roughly: $ { seq 1 314290; env; } | wc -c 2091391 linux sysconf The maximum length of the arguments to the exec(3) family of functions. Must not be less than _POSIX_ARG_MAX (4096). POSIX 2004 limits.h Maximum length of argument to the exec functions including ...

When you run findinfiles {*.js,*.html,} {release,dev,} "span", here is what happens: Bash parses quotes and splits the command into words: findinfiles, {*.js,*.html,} {release,dev,} span. Bash expands the braces, resulting in the list of words findinfiles, *.js, *.html, release, dev, span. Bash expands the wildcard patterns *.js and *.html to the list of ...

bash expands {a,b,}1 to a1 b1 1.. Your command expands to grep --color=auto -iRnHr --include=*.js --include=*.html --include= --exclude-dir=release --exclude-dir=dev --exclude-dir= span (in a directory without any js and html files, otherwise it would be an include for every file) You can quote the parameters, but that is probably not ideal... findinfiles ...

Text processing tools traditionally read input from standard input when you don't specify any file name on the command line. You can check whether there are command line arguments by testing the $# variable. Assuming that process_file reads from standard input if you don't pass it an argument: if [ $# -eq 0 ]; then process_file else for x; do ...

With GNU find (i.e. under non-embedded Linux or Cygwin), you can use -regex to combine all these -path wildcards into a single regex. find . -regextype posix-extended \ -type d -regex '\./(\..*|Music|Documents)' -prune -o \ -type f -regex '.*(\.(bck|bak|backup)|~)' -print0 | xargs -0 --no-run-if-empty trash-put With FreeBSD or OSX, use -E ...

As far as I know, there is no option to tell find to read patterns from a file. An easy workaround is to save the patterns I want to exclude in a file and pass that file as input for a reverse grep. As an example, I have created the following files and directories: $ tree -a . ├── a ├── .aa ├── .aa.bak ├── a.bck ├── b ├── .dir1 │   └── bb1.bak ├── dir2 │ ...

I'm not an expert at regular expressions, but this works, at least for what you described. #!/bin/sh argument="$1" #if [[ $argument =~ [a-zA-Z]*5\.0\.3[a-zA-Z]+ ]]; then# only works on bash if echo $argument | egrep -q '[a-zA-Z]*5\.0\.3[a-zA-Z]+'; then #echo "Found: ${BASH_REMATCH[0]}" # for bash echo "Match Found" # you can check for $argument at ...

I would recommend following the advice of @warl0ck in the general case -- create a new script, e.g. /path/to/newscript: #!/bin/bash /path/to/script argument and then run that using at: at -f /path/to/newscript 17:45 This makes it easy to adjust whatever arguments are needed, run multiple commands, etc. Alternatively, for occasional or one-off use, ...

The page that you linked to about ARG_MAX states that as of kernel version 2.6.23 it is 1/4th the stack size. It even links to the git commit responsible.