Ok, I hope this question makes some sense but what is the difference between a bash shell and a bash terminal? Example. When I first open up terminal I have a prompt with my current dir and my user name. In the terminal window header it says -bash- , when I type echo $SHELL I get bash. So by default the shell is bash. Where my confusion comes into play is when I type bash. My prompt then goes to bash-3.2$.Obviously it's a different mode. Are ther any major differences? I have read the man page with no answer. I understand what a bash shell is but just do not get the difference. Thanks for the clarity in advance.
There is no difference, they are both instances of the bash shell.
The reason you are seeing a different prompt is that your initial login shell sources ~/.bash_profile where presumably you have your prompt set. When you type bash it invokes another shell but because this one isn't a login shell, it doesn't source ~/.bash_profile and so you get the default prompt.
If you were call bash -l, (which invokes bash as if it were a login shell) I bet you would see that your original prompt remains
Related
I am seeing a strange problem with the storing of an env in mac os.
I set custom env in ~/.bash_profile
export MYENV=user
Then ran the . ~/.bash_profile and then I printed the env using
printenv then I can see the MYENV=user in the list.
If I close the terminal and reopen and execute printenv then I could not see MYENV in the list still I can see the export MYENV=user in ~/.bash_profile. It seems strange to me.
I am using Mac os High Sierra 10.13.6.
Could some body please tell me what mistake I am doing?
Note that ~/.bash_profile is only run for login shells. From the man page:
When bash is invoked as an interactive login shell, or as a non-interactive shell
with the --login option, it first reads and executes commands from the file
/etc/profile, if that file exists. After reading that file, it looks for
~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and exe-
cutes commands from the first one that exists and is readable. The --noprofile
option may be used when the shell is started to inhibit this behavior.
So if you terminal isn't launching the shell with -l, --login or with $0 having a leading hyphen it won't be a login shell and thus won't read ~/.bash_profile. You may need to reconfigure how your terminal launches the shell if you want the shell to read that config script.
On the other hand ~/.bashrc is always read by an interactive shell. So if you put the export in that script it should do what you expect. It certainly does for me. You replied to Amila that it didn't work for you. So I'd suggest a simple experiment. Open two terminal windows. In one edit ~/.bashrc and add these two lines:
echo running .bashrc
export WTF=abc
In the other window just run bash. It should echo that message and echo $WTF should print abc. Now open a new terminal window. If you don't see that message and the env var isn't present then something is inhibiting reading that config script. Possibly the shell is being run with the --norc flag.
~/.bash_profile is executed before the initial command prompt is returned to the user, which means after a new login. Try adding the environment variable to ~/.bashrc instead.
I'm looking for a way to make the cygwin terminal more compact, or an alternate terminal that is more compact. Currently, every command I enter has a header line above it with username and pwd, and there is a blank line trailing every command. For instance:
username ~
$ cd tmp
username ~/tmp
$
3 lines for every 1 line of command. I frequently work on a small screen, which makes all this wasted space quite irritating. Is there a setting somewhere I can alter to prevent all this wasted space? Or, perhaps another terminal?
Thanks in advance.
That's the default shell prompt set by Cygwin.
To use a smaller prompt in your current terminal:
PS1='$ '
To make the change permanent, put that command in your ~/.bashrc file.
You can set the prompt to just about anything you like, as explained by the bash manual (there are several variables that control different prompts; $PS1 is the main one).
It's important to remember than in Cygwin (as in Linux and Unix), the terminal program is a separate program from the shell that runs in it. The prompt is controlled by the shell; bash is the default. The graphical display is controlled by the terminal emulator, which could be rxvt, mintty, xterm, or even the Windows terminal that normally runs a DOS-like shell.
What you're seeing there is the prompt, as stored in the environment variable PS1
echo $PS1
will show you how it's created. By the way, that prompt is managed by the bash shell, not by the terminal.
export PS1=$
will give you just a $ prompt
export PS1="$ "
will leave some room behind the prompt. There are many more possibilities, here is a nice tutorial.
bash reads its settings from a file called ~/.bashrc aka a file called .bashrc in your home directory. Note that due to the initial dot in the name ls won't show the file by default, ls -a or ls -la will.
I would Recommend we go with modern terminals using Cygwin-X as shown in the below interactive menu
I love Xfce Terminal which allows creating tabs and new windows with font options and color options
I have the following lines in my .bashrc which I would like to get executed upon logging in through ssh.
csh
source /x/y/.cshrc
source /x/y/z/sourceme
But the problem is that only the first command is being executed correctly.
(csh prompt is coming up)
The following source command is not effected.
I noticed that there are some errors which are thrown from bash (not csh) for the 'source' command
I read somewhere that this may be due to .bashrc getting executed multiple times. And source commands trying to get executed in bash itself rather than csh.
I want all the three commands to be executed one after other upon log-in. how can I do that? I tried .bash_profile .bash_login etc. Also I don't have write access to /etc/profile
The "commands" are interpreted by the bash shell. They aren't bytes to be fed to the terminal. What happens is that csh runs interactively, and once it exits bash will source the two (presumably csh) script files.
It looks like you're simply trying to change your shell to csh (why, I have no idea). Have you tried using chsh for that?
If you want to run these commands in csh, move them to your .cshrc.
A word of caution, though; using csh for absolutely anything raises the question, do you really think you know what you are doing? Why?
source is a "bashism", that is to say it won't work in other shells. Use . instead.
How can I tell what type my shell is? ie, whether it's traditional sh, bash, ksh, csh, zsh etc.
Note that checking $SHELL or $0 won't work because $SHELL isn't set by all shells, so if you start in one shell and then start a different one you may still have the old $SHELL.
$0 only tells you where the shell binary is, but doesn't tell you whether /bin/sh is a real Bourne shell or bash.
I presume that the answer will be "try some features and see what breaks", so if anyone can point me at a script that does that, that'd be great.
This is what I use in my .profile:
# .profile is sourced at login by sh and ksh. The zsh sources .zshrc and
# bash sources .bashrc. To get the same behaviour from zsh and bash as well
# I suggest "cd; ln -s .profile .zshrc; ln -s .profile .bashrc".
# Determine what (Bourne compatible) shell we are running under. Put the result
# in $PROFILE_SHELL (not $SHELL) so further code can depend on the shell type.
if test -n "$ZSH_VERSION"; then
PROFILE_SHELL=zsh
elif test -n "$BASH_VERSION"; then
PROFILE_SHELL=bash
elif test -n "$KSH_VERSION"; then
PROFILE_SHELL=ksh
elif test -n "$FCEDIT"; then
PROFILE_SHELL=ksh
elif test -n "$PS3"; then
PROFILE_SHELL=unknown
else
PROFILE_SHELL=sh
fi
It does not make fine distinctions between ksh88, ksh95, pdksh or mksh etc., but in more than ten years it has proven to work for me as designed on all the systems I were at home on (BSD, SunOS, Solaris, Linux, Unicos, HP-UX, AIX, IRIX, MicroStation, Cygwin.)
I don't see the need to check for csh in .profile, as csh sources other files at startup.
Any script you write does not need to check for csh vs Bourne-heritage because you explicitly name the interpreter in the shebang line.
Try to locate the shell path using the current shell PID:
ps -p $$
It should work at least with sh, bash and ksh.
If the reason you're asking is to try to write portable shell code, then spotting the shell type, and switching based on it, is an unreliable strategy. There's just too much variation possible.
Depending on what you're doing here, you might want to look at the relevant part of the autoconf documentation. That includes an interesting (and in some respects quite dismal) zoology of different shell aberrations.
For the goal of portable code, this section should be very helpful. If you do need to spot shell variants, then there might be some code buried in autoconf (or at least in one of the ./configure scripts it generates) which will help with the sniffing.
You can use something like this:
shell=`cat /proc/$$/cmdline`
Oh, I had this problem. :D
There is a quick hack, use ps -p $$ command to list the process with PID of the current running process -- which is your SHELL. This returns a string table structure, if you want, you can AWK, or SED the shell out...
The system shell is the thing you see when you open up a fresh terminal window which is not set to something other than bash (assuming this is your default SHELL).
echo $SHELL
Generally, you can find out all the constants defined by running
set
If the output is a lot of stuff then run
set | less
so you can scroll it from the top of the command line or
set > set.txt
To save the output to a file.
Invoking a different interactive shell to bash in your terminal does not mean that your system shell gets changed to something else i.e. your system shell is set to bash although you invoke a csh shell from a bash shell just that one session.
The above means that typing /bin/csh or /bin/python in bash or whatever does not set the system shell to the shell you invoked, at all.
If you really want to see the SHELL constant change then you need to set it to something else. If successful you should see the new shell whenever you open a fresh terminal...
It's old thread but...
In GNU environment You can sh --help and get something like
BusyBox v1.23.2 (2015-04-24 15:46:01 GMT) multi-call binary.
Usage: sh [-/+OPTIONS] [-/+o OPT]... [-c 'SCRIPT' [ARG0 [ARGS]] / FILE [ARGS]]
Unix shell interpreter
So, the first line is shell type =)
I just started using a Solaris 10 (Sparc) box where I telnet in and get confronted with a very unfriendly interface (compared to the standard bash shell I use in cygwin or linux) --- the arrow keys do not work as I expect them to. Being an NIS system, changing the shell is not as easy as using the "chsh" command. And setting the SHELL environment variable in ~/.login and ~/.profile is not working for me. So I'm thinking that I may need to write a script to determine if bash is running the script and starting bash if the answer is no. My first attempt, trying to invoke /bin/bash from ~/.profile seems to work but kind of doesn't feel right. Other suggestions? And how do I tell programmatically which shell is actually executing?
You can tell what shell is running with echo $0. For example:
$ echo $0
-bash
If you're changing shell you probably want to replace the current shell process rather than be a child of it, so use exec.
Also, you want to pass bash the -l flag so it acts as if it has been called as part of the login process.
So you'll want something like:
exec bash -l
You are probably running with ksh(1) on Solaris. You have several options, read the manpage for ksh and configure it or install another shell you're more familiar with like bash. I'd personnaly recommend zsh.