I'm using GNU bash that is installed as git bash. On startup I need to change directory, so I'm doing it like this:
"C:\Program Files\Git\bin\sh.exe" --rcfile "./cd.sh"
Where cd.sh just contains cd /d/ command. Everything works fine here. Now I'm trying to get rid of cd.sh file and pass command to the shell as a parameter yet I want it to remain interactive, so I'm doing like this:
"C:\Program Files\Git\bin\sh.exe" -ic "cd /d"
It executes the command (tested with echo command) but then exits. Why doesn't it stay interactive?
From man bash:
An interactive shell is one started without non-option arguments and without the -c option ...
From man dash:
If no args are present and if the standard input of the shell is connected to a terminal (or if the -i flag is set), and the -c option is not present, the shell is considered an interactive shell.
Related
I am working in WSL Ubuntu
When i execute command directly, show wrong path
C:\Users\Administrator>bash -c 'pwd'
/
Expected output :
C:\Users\Administrator>bash -c 'pwd'
/mnt/c/Users/Administrator/
How to fix this
I'm not able to reproduce this on any of my systems. Is it possible that you have a cd / (or equivalent) somewhere in one of your startup scripts?
First, let's change that to use wsl.exe command in place of the deprecated bash.exe command:
wsl pwd
That should give you the same (wrong) result that you are already seeing, but let's confirm that.
Then, to start WSL and tell Bash to not execute your startup scripts, try:
wsl -e bash --noprofile --norc -c pwd
Then try the shorter:
wsl -e pwd
The -e/--exec argument tells WSL to run the command in place of the shell, so Bash (and its startup files) should never get called in the first place.
I was assigned an account for log in to a remote server, and I want to change my default shell.
I tried chsh command but it says: chsh: "/public/home/{my_id}/bin/zsh" is not listed in /etc/shells.
If you don't have permission to install zsh system wide, a quick fix is to append exec ~/bin/zsh -l to ~/.bash_profile (if bash is the current shell), or an equivalent rc file for the current login shell.
zsh -l starts zsh as a login shell.
exec COMMAND replaces the current process with COMMAND, so you'll only have to type exit (or press ctrl+d) once.
~/.bash_profile is executed when bash starts as a login shell, you can still run command bash normally.
Depending what is in ~/.bash_profile (or equivalent), you may wish to avoid executing its other contents, by putting exec ~/bin/zsh -l at the start of the file (not the end), and copy/port anything important over to the zsh equivalent, $ZDOTDIR/.zprofile.
I might also do export SHELL="$HOME/bin/zsh", although I'm unsure of the full effects of setting SHELL differently to that specified for your user in /etc/passwd, to a shell not in /etc/shells, and to a shell binary in your home path.
First check all the shells available on your linux system
cat /etc/shells
Use chsh command line utility for changing a login shell with the -s or –shell option like this.
# chsh --shell /bin/sh tecmint
So I have this shell script that checks and then concats an environmental variable to /etc/environment, then reloads the file without having to logout/login:
#!/bin/sh
portvar="PORT=5000"
echo $portvar
grep -q $portvar /etc/environment && echo "EV already in" || echo $portvar >> /etc/environment
set -a; source /etc/environment; set +a;
When I run it, I get the error ./test.sh: 5: ./test.sh: source: not found. However, if I run set -a; source /etc/environment; set +a; directly in the terminal it updates the environmental variable just fine. I have no idea what the set command does, I just found it in another stack overflow question.
Any idea why it runs in the terminal directly but not in the .sh file?
Thanks
/bin/sh on your system is likely some shell that isn't bash and doesn't implement the source command. On my Ubuntu 20.04 system /bin/sh is actually dash.
The source command is not defined by POSIX as part of the shell command language nor is it one of the required special built-in utilities. It's a non-standard feature provided by bash. However, the . command, which does the same thing, is specified by POSIX.
So you can use . instead, e.g. . /etc/environment. Or if you want to keep using source, then you need to have your script run by bash or some other shell that supports it, by changing the shebang line to #!/bin/bash.
There is a tool called checkbashisms that can help you find unintentional uses of bash-specific features in your scripts. When run on your script, it flags this:
possible bashism in foo.sh line 5 (should be '.', not 'source'):
I'm writing a simple bash script but the commands within the script do not anything. However it works when I copy/paste the commands directly to the command line.
#!/bin/bash
today=$(date +%B-%A-%d-%Y)
expr='clear|ls|cd'
history | grep -v -E $expr > histor$today.txt
history -c
Suggestions?
Another question: is possible to call and execute any command of the command line?
NOTE: I would like to make a script that saves my command history except the commands "clear, ls, cd" and then use crontab to save it periodically.
By default, the history facility is only enabled in interactive shells, not shells running scripts. You can put
set -o history
at the beginning of your script to enable history.
Also, each shell invocation has its own history, it's not shared between shells. So enabling history in the script will not give it access to the history of your interactive shell. So the only history that your script would find are the commands that were executed in the script after set -o history.
What you should do instead is define a function in your .bashrc.
gethist() {
history | grep -v -E 'clear|ls|cd' > $(date +'histor%B-%A-%d-%Y.txt')
}
If I open a shell into a machine with: putty -load session_name and then execute a command to add a job to a Grid queue on a linux system (qsub -cwd -b hostname), everything works fine.
But if I add the command to a text file, and then do putty -load session_name -m file.txt, I get qsub: command not found
If I back out and simplify the text file to be only the command hostname and use the -m option, it also works fine.
If I use the Connection->SSH->Remote command, and do something similar as the -m command, I get the same results as from the command line.
I'm very much a novice at linux systems, and this seems like it should be a simple fix to tell something that 'qsub' exists somewhere. Either that or there are some restrictions on these remote access things...
Edit:
Ok, so the initial question was how to run it--and I figured that out (add an absolute path), but there are other environment variable issues as well. It appears that qsub requires the SGE_ROOT variable to be set, but that isn't set for the remote commands window either.
So, a better question is, how do I get the putty remote commands shell (using -m) to open with the same properties and setup as a manual command line shell?
qsub is on your path when you log in interactively, but in the non-interactive shell it is not. Give the full path in the script, or set PATH in the script, and you ought to fix your problem.
It seems you need to run your command in the context of an interactive session, but the sshd protocol doesn't directly do that. So try invoking the command indirectly through /bin/sh.
/bin/sh -i -c "qsub -cwd -b hostname"
The -i makes the shell initialize itself like an interactive one, so it will load all the environment variables in your .profile or .bashrc that are loaded in a real interactive shell. The -c provides a command to run within that interactive shell.
You shouldn't have to explicitly set any paths this way since it works in an interactive session.