I want to run a script called tuxsay that combines fortune and cowsay to have tux say some words of wisdom. I made an alias in by .bash_aliases calling it tuxsay and executing the script
FORTUNE= $(fortune)
cowsay -f tux $FORTUNE
I then have a script that will spawn a new terminal and I want it to output the results of my first script then allow me to work in the terminal, something like
xterm -e "tuxsay&"
So how can I spawn a new terminal use cowsay then allow me to work in it?
Specifics: I have a startup script that will spawn applications that I typically use, and I want it to spawn a terminal that runs my tuxsay script then allows me to work. I am on Ubuntu 12.04 LTS and am running dwm 6.0
Why not just add your command to your .bashrc file? Then it will be run every time a new interactive shell is started. You can test if the $TERM variable contains "xterm", and make your output conditional upon that. e.g. add the following line to the end of .bashrc:
[[ "$TERM" =~ xterm ]] && tuxsay
Update
While I think the above is still probably the most useful general answer, I noticed a few more things:
tuxsay is a bash alias. bash aliases are only understood within bash itself, but when you pass a command to xterm -e, that command is executed directly by the xterm without any bash involvement. The system won't be able to find and execute a file called "tuxsay" and will fail.
If executed from bash, the & character will put tuxsay command (alias) in the background, but this doesn't really help here. What you need is a new shell to start up once tuxsay is done.
Be careful with .bash_aliases. I noticed on my Redhat-based system that aliases placed in this file were not working, because .bash_aliases file is not sourced in. (My Bash aliases don't work) So it looks like .bash_aliases is sourced by default from Ubuntu-based systems, but no guarantees for others.
With the above in mind, if you definitely want tuxsay to run on a per-xterm basis – i.e. you want to specify this on the xterm command line – you could do the following one-liner:
xterm -e 'cowsay -f tux $(fortune); bash'
This passes the compound command cowsay -f tux $(fortune); bash to xterm. This compound command consists of two commands: first do the cowsay thing, then start bash.
You could also put these two commands in a shell script and pass the shell-script to xterm.
Related
I use vim's :! external command function all the time, usually providing % as an argument to the shell command. For example :
:!psql -f %
I also have a lot of bash shell functions in my .bashrc that I use. For example:
psql-h1 ()
{
/usr/bin/psql -hh1 -d mydb "$#"
}
These bash functions aren't available from :! inside of vim. Is there a way to make them available?
Export your functions. That is:
psql-h1() { /usr/bin/psql -hh1 -d mydb "$#"; }
export -f psql-h1 ### <-- THIS RIGHT HERE
This will make them available to any copy of bash run as a child process, even if it's a noninteractive shell and so doesn't read .bashrc.
An alternative to exporting your functions (which may no reach Vim is there's a non-Bash shell in between; see here for such a case), you can instruct Vim to start an interactive shell, so that your .bashrc is read. Just pass the -i flag to Bash, via Vim's :help 'shellcmdflag'.
:set shcf=-ic
This answer assumes your vim isn't actually using bash to invoke the remote commands - this can be tested by running :!echo $0 in vim.
Specifically for vim, add:
set shell=/bin/bash
to your .vimrc.
In general, there's two strategies I've found to sometimes work when trying to get other programs to invoke my preferred shell:
export SHELL=/bin/bash
in eg. the .profile file, or:
ln -fsn /bin/bash /bin/sh
which updates the sh symlink to point to bash instead.
On many systems (certainly Ubuntu), /bin/sh is a symlink to a sh-compatible shell (such as bash), rather than the sh shell itself. Given this fact, some programs (I've seen this behaviour in GHC) seem to invoke /bin/sh, so changing where it points to will cause the programs to use bash instead.
The accepted answer didn't work for me. I'm going to go with setting shcf, as suggested elsewhere:
:set shcf=-ic
but another solutions is
!source ~/.bashrc && psql ...
Unfortunately, no solution allows the auto-completion for the command I'm creating to work properly. (The auto_completions suggested are for names of files in my current directory, rather than the ones I specified as follows in .bashrc
complete -F _generate_foo_completions foo
I am trying to run a server. the command x_server.sh do not work for my ubuntu 14.04 but it runs when I give the command bash x_server.sh.
It has adviced that the products should not run as a daemon thread.
What I want to know is what exactly this bash command do, is it run as a daemon thread when i do so and what are the alternative ways there for me to use to make that command x_server.sh work.
On Ubuntu the default shell is Dash, not Bash. Presumably your x_server.sh script starts like this:
#!/bin/sh
You should change it to this:
#!/usr/bin/env bash
That will make it auto-select the best "bash" on the system rather than the default shell which is dash which has different (mostly fewer) features than bash.
And of course you need to do the usual chmod +x x_server.sh to make it executable in the first place, and run it as ./x_server.sh unless it's in your $PATH.
I am not a Solaris expert and I am trying to create a shell script that will change my prompt to PWD and the ksh to bash and I have this:
PS1='$PWD $ ' exec bash --noprofile --rcfile /dev/null
or
PS1='\w $' exec bash --noprofile --rcfile /dev/null
Both of them dont work from a sh. if i add them from the command line then the first time my bash appears on prompt and the second time the PS1='$PWD $' kicks in and my prompt changes.
Firstly, why is PS1='$PWD $' not working from shell script . and why do i have to run the command from command line twice to acheive my results.
Also, in my export/home/syed/ directory there are three files local.login, local.profile, and local.cshrc. is there any way i can use them that when ever i log in i dont need to run my shell script and upon login i get bash shell and my prompt as i want it
(am i asking too much, i dont like the ksh as it does not have any features like up arrow recall last commands and tab auto complete features)
thanks
Syed...
When you exec from within a script, the script is what is replaced, not the parent shell.
Try sourcing the script rather than running it.
Also, in Solaris, you can use passwd -e to change your login shell.
You may be able to symlink ~/.profile to your existing ~/local.profile (or similar). Note that .cshrc is for the C Shell and is not compatible with ksh or Bash.
If you want that your default shell will be bash, change it in /etc/passwd
When you exec bash it sets up its own environment from scratch. Pass it an --rcfile containing the settings you would like for it to inherit.
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.