This question already has an answer here:
Is there any established order for 'ls' arguments?
(1 answer)
Closed 5 years ago.
I am testing Hugo static blog generator which comes with themes and example sites within them.
In order to easily use exampleSite, I just copy the content it's content to Hugo project root. While I did this, I noticed that where, I put the -flag args seems to be important.
Is this is a normal bash behavior or something introduced by zsh?
This command didn't work
cp themes/hugo-theme-bootstrap4-blog/exampleSite/* . -R
This command worked!
cp -R themes/hugo-theme-bootstrap4-blog/exampleSite/* .
cp is its own command, provided by your OS vendor. Neither bash nor zsh controls the behavior of cp.
The POSIX standard only requires cp to accept options before arguments. This is given in POSIX utility syntax guidelines, entry #9:
All options should precede operands on the command line.
GNU tools go beyond this requirement, accepting options after arguments unless -- is given prior (as described in guideline #10).
Related
This question already has answers here:
How can I check if a program exists from a Bash script?
(39 answers)
Closed 6 years ago.
I've read in some bash FAQ a while ago (that I don't remember), that which should be avoided and command -v preferred.
Why is that so? What are the advantages, disadvantages of either one?
Well...
command is likely built in to your shell, and with the -v option will tell you how your shell will invoke the command specified as its option.
which is an external binary, located at /usr/bin/which which steps through the $PATH environment variable and checks for the existence of a file.
A reason to select the former over the latter is that it avoids a dependency on something that is outside your shell.
The two commands do different things, and you should select the one that more closely matches your needs. For example, if command is built in to your shell, command -v command will indicate this with its output (through the non-existence of path), but which command will try to point to a file on your path, regardless of how command would be interpreted by your shell.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I am new to scripting. While looking at an ex-employee's R code there's a line where they call to the command line. The line/purpose is not something I know how to search for online. Any help is appreciated.
The line of code in question:
/folder1/folder2/folder3 -s file_1_name -n file_1_name -e file_2_name > file_1_name.log 2>&1
Things to note:
The syntax is bash (or derived from bash, 2>&1), though when I use the command line to check what shell is used it says tcsh (example redirect >&, no numbers).\
File names (above) are just the name, not the extension. Example: a file named "ex.sch" then file_1_name would be "ex". The only extension in the line of code is for the log file that is made.
The files are .sch files. According to this site these are for schematics, though I highly doubt that that's what they are.
The line/purpose is not something I know how to search for online. [...]
The line of code in question:
/folder1/folder2/folder3 -s file_1_name -n file_1_name -e file_2_name > file_1_name.log 2>&1
Interpreted as a Bash command line, that is executing the program or script /folder1/folder2/folder3, passing it the six command-line arguments -s file_1_name -n file_1_name -e file_2_name. It is furthermore directing the program's standard output and standard error to a file named file_1_name.log in the working directory, creating that file if it does not already exist and replacing its contents if it does. If the command works then folder3 must in fact be a regular file or a symbolic link to one, not a directory / folder.
We cannot tell you more. The significance of the command-line arguments and the behavior of the program in general are not conveyed by the name you provided. In particular, the fact that some of the arguments correspond to file names you recognize with their suffixes removed is probably meaningful, but we cannot tell you the meaning.
Additionally, you observe that
when I use the command line to check what shell is used it says tcsh
Undoubtedly you have checked what your own default shell is. That is not indicative of what shell R will use to run the command.
This question already has answers here:
What does double-dash do when following a command?
(4 answers)
Closed 3 years ago.
https://docs.docker.com/compose/startup-order/
Could someone point me to some docs or general knowledge of what the "--" means in this docker command?
command: ["./wait-for-it.sh", "db:5432", "--", "python", "app.py"]
I've always been weak at bash and unix things and wanted to learn more.
The precise semantics of options depend entirely on the command. In this case, examine the documentation or source code of wait-for-it.sh. But commonly, a double dash is used to signal the end of options. Here, it looks like the arguments before the double dash are parameters for the script itself, and the stuff after the double dash is a command line (which could conceivably contain additional options, which should not be misunderstood as options for wait-for-it.sh itself).
This question already has answers here:
Brace expansion with variable? [duplicate]
(6 answers)
Closed 5 years ago.
How do I expand a brace expansion that originally come from a string variables ? Note that the string variable is a requirement.
#!/usr/bin/env bash
TEXT_DIRS='opt/*/{doc,gtk-doc}'
My intention is reading a bash source from zsh, or maybe other language as well such as Perl or Python. Get the configuration from /etc/makepkg.conf, as below.
DOC_DIRS=(usr/{,local/}{,share/}{doc,gtk-doc} opt/*/{doc,gtk-doc})
It is all, for just, learning purpose.
Is that possible, to expand from string ?
The tricky thing here is that once Bash resolves the environment variable, it doesn't make another pass to process its contents again. You'd have to evaluate the content of the variable in another pass of the shell ( eg another shell command).
Here's one way to do that:
bash-4.4# TEXT_DIRS='/usr/*/{bin,src,lib}'
bash-4.4# bash -c ls\ $TEXT_DIRS
ls: /usr/*/src: No such file or directory
/usr/local/bin:
/usr/local/lib:
Here, I'm dynamically generating a shell command that I then evaluate to handle the 2nd expansion. (I took the liberty of changing the paths to something that would match on typical systems, so make sure to change it back if you try to test).
Dynamically generating code is always dangerous, if you can't trust the input. That's essentially how command injection attacks work. But use of eval in your own shell with trusted input is more or less "safe", though I rarely find myself using it unless in a contrived scenario like yours, or some of my own worse ideas.
This question already has answers here:
Should I use a Shebang with Bash scripts?
(8 answers)
Closed 8 years ago.
Suppose you have a bash script B, that you are sourcing from another bash script A. B has a bunch of variable and function definitions. A is the main driver script. Do you need the #!/bin/bash line on top of both A and B? What happens if you do and if you don't?
The shebang is only mandatory for those scripts, which shall be executed by the operating system in the same way as binary executables. If you source in another script, then the shebang is ignored.
On the other hand. IF a script is supposed to be sourced, then it is convention to NOT put any shebang at the start.
The shebang is used if you run the script directly as an executable file (for example with the command ./script.sh). In this case it tells the operating system which executable to run.
It's not required and has no effect if you for example write bash ./script.sh or source the script.
You should use shebang in all scripts especially those using any non-sh compatible features.
In Debian for example, default shell is dash (not bash). If you use bash-only feature and don't specify that this script should be interpreted by bash it may fail even on linux. It will fail on Solaris or HP-UX almost for sure.
If your file is to be only sources by other script, then you can omit shebang line but do not set executable permission. Also for such files is good to keep /bin/sh compatibility.
I strongly recommend to read DashAsBinSh.