Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 8 years ago.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Improve this question
In my terminal, I do
$ myprogram myfile.ext.
I want to be able to do the same via the command /bin/bash, but it is not working.
I tried
$ /bin/bash -c -l myprogram myfile.ext
but it is not working. It seems that my program is launched but without my file.ext as an option (as an input file)
Does anyone has a clue on how to do that?
Why I ask this question
I want to launch myprogram via NSTask in an a program I am writing for OSX, with the cocoa framework. If I simply ask NSTask to launch my program, it seems that some variable environment are missing. So, what I try is to launch a shell and inside this shell to launch myprogram.
Drop the -c altogether. From the manpage:
bash [options] [file]
…
Bash is an sh-compatible command language interpreter that executes commands read from the standard input or from a file.
Thus, you can execute your program via
bash myprogram myfile.ext
and myfile.ext will be the first positional parameter.
bash -l myprogram myfile.ext
will work as well, (but whether or not bash is invoked as a login shell seems tangential to this question.)
-c string
If the -c option is present, then commands are read from
string. If there are arguments after the string, they are
assigned to the positional parameters, starting with $0.
You need to quote the command passed in as string so it's treated as a single argument for the -c option, which then gets executed normally with the argument following the command, i.e.
/bin/bash -c -l 'myprogram myfile.ext'
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 am completely new to Mac OS and I am trying to figure out how to display in terminal all flags for echo command. When I do man echo it only shows me one flag which is -n and I am pretty sure there are many more.
I've googled it but found nothing.
Thank you beforehand!
For shell builtins such as echo, the man page does not offer an accurate description, since it describes the binary (usually found in /bin), not the builtin.
For help on the built-in commands in Bash, use
help echo
For instance, on my version of macOS this shows me:
echo: echo [-neE] [arg ...]
Write arguments to the standard output.
Display the ARGs, separated by a single space character and followed by a
newline, on the standard output.
Options:
-n do not append a newline
-e enable interpretation of the following backslash escapes
-E explicitly suppress interpretation of backslash escapes
…
In zsh, the closest equivalent is man zshbuiltins, which shows the documentation for all built-in commands. To find a given command in it, type / echo and hit Return. Note that there are multiple spaces between / and echo! This isn’t necessary, but it often filters out false hits.
echo is a function of your shell and it behaves differently if you have a different shell. zsh or more 'advanced' shells may support extra args, but i've for one not heard about other args to echo than -n (which removes the trailing newlines).
macos is closer to freebsd than linux and it comes bundles with bash (Bourne again Shell), but in normal scenarios you should only assume that sh or ash (in Alpine) is available. E.g. while you may be able to use extra flags for echo with a different shell, you shouldn't expect that shell to be available or default on a target system.
I think a better way to find out what you want is to google what you want echo to do and likely there'll be lots of ways described how to do that outside echo (printf, cat, tee or similar).
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 1 year ago.
Improve this question
I test the script in WSL2
Here is my script:
#!/usr/bin/bash
echo "testing..."
printf "testing..."
It work fine if I run like
bash test
source test
. test
But it output nothing if I add the path the script located in to PATH and run
test
Why and how can I fix it?
test is a bash built-in. POSIX systems will also have a test executable.
When you enter a command without specifying a path to the executable, bash will first check if the command is one of its built-in commands before searching for the executable in the PATH. If the command matches the name of one of the bash built-ins, it will run the built-in.
If you still want to run your script without specifying its path, there are two ways to do it:
Recommended: Rename your file, and then run it with its new name (your script file needs to have its executable permission bit(s) set).
Make sure your script has its file permissions set so that it is executable, make sure your PATH is set up so that your test will be found before the system's test, and then run env test to run your script. env will search your PATH to find your test executable, and then it will execute it.
Ultimately, option 2 is not recommended, because it can be brittle to reorder your PATH, and it can be confusing (for you and for others) to have a second test binary on your system.
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.
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 am trying to ssh into my amazon server. I have two ways of doing it, one works and one doesn't, and I'm not sure why the second one does not work.
First way:
ssh -i path-to-pem-file username#public-ip
This works.
Second way:
ssh -i "path-to-pem-file" username#public-ip
This results in "Warning: Identity file "path-to-pem-file" not accessible".
Both of the above commands are run from the terminal on Mac OSX. Why do the double quotes break the statement? thanks.
If your using shell expansion or other special characters their special meanings will not be interpreted when quoted. They are considered literal values.
You can replicate this with the ~ or special character for $HOME
Doesnt work
ssh -i "~/mypemkey.pem" ec2-user#somehost
Works
ssh -i ~/mypemkey.pem ec2-user#somehost
Essentially the ssh application is trying to find a literal file path ~/ instead of /Users/someuser/ when expanded.
Want to see it in action under the hood.... test it!
Create a simple bash script
echo "echo \$1" > test.sh
Execute it
/bin/bash test.sh ~/Desktop
outputs: /Users/phpisuber01/Desktop
/bin/bash test.sh "~/Desktop"
outputs: ~/Desktop
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.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
The very first line of my expect script fails. Here are the entire contents of my script and it fails:
#!/usr/bin/expect -f
And it fails right off the bat with
": no such file or directory
as my response. Expect is in fact installed and is located in /usr/bin/ and I am running this from root. I have no extra spaces or lines before the # sign either. Of course there was more to the script originally but it fails way before it gets to the good stuff.
Tried it and here is the result: /usr/bin/expect^M: bad interpreter
Is it possible that there's a Windows newline (the ^M) in there that's confusing the script? You can try od to see what newline character(s) is after the expect and tofromdos or an editor (e.g. emacs in hexl-mode) to remove it. See the man pages for more info.
I had this issue and found I didn't have the expect interpreter installed! Oddly enough, if you ran the command in the shell it worked. However, through a shell script I got this error:
/usr/bin/expect: bad interpreter: No such file or directory
I fixed it by simply installing the Expect interpreter. The package name that was chosen was: expect libtcl8.6
Just run:
sudo apt-get install expect
Your line endings are wrong. Shove it through dos2unix or tr -d '\r'.
I don't really know expect, to be honest, but when I run that on my system it "works" fine. Nothing happens, but that's what I'd expect. I don't get any error message. According to the man page,
#!/usr/bin/expect -f
is the correct way to start your script. Expect then slurps up the script you are executing as the cmdfile.
The way I got it to reproduce the problem was to actually put a ^M at the end of the line instead of a normal newline (saw Bert F's response and that prompted me to try it). I'm sure vim's :set list command will show any odd characters.
If you observe the error, there was a windows newline character, that is added because its copied from windows machine via mail or winscp. So to avoid this error copy the script using scp linux to linux and execute the script.