I have problem with refactoring bash command into tcsh-friendly command. Don't know the tcsh syntax very well so the error im receiving doens't give me any clue.
The whole bash script was about adding modules on server
MODULEPATH=/app/modules/0/modulefiles:/env/common/modules
export MODULEPATH
module() { eval `/app/modules/0/bin/modulecmd sh "$#"` ;}
I changed first two commands to tcsh already
setenv MODULEPATH /app/modules/0/modulefiles:/env/common/modules
set MODULEPATH
But i dont know how to change the syntax of last command. Console is returning me error "Badly placed ()'s.".
Can I ask for little lesson what to change in this command to be tcsh-friendly?
chepner is right saying tcsh doesn't have functions at all and you'd have to write an alias instead. That's not much of an effort for your one-line function:
alias module 'eval `/app/modules/0/bin/modulecmd sh \!*`'
Basically, we prepend alias, remove () and {}, quote and replace "$#" with \!*.
The module command you want to port from bash to tcsh already comes with an initialization file to the tcsh shell. For all shells or scripting languages module is compatible with, there is an initialization file provided in the init directory of the software.
So from your example, Modules is installed in /app/modules/0, so you should have a /app/modules/0/init directory and a /app/modules/0/init/tcsh script to initialize the module command for tcsh. You just have to source it to initialize the module command:
source /app/modules/0/init/tcsh
As Armali says, the module command on tcsh is defined with the alias shell command.
With recent version of Modules (version 4+), you also have the possibility to define the module command in your current shell session with the autoinit subcommand of the modulecmd script:
eval `/app/modules/0/bin/modulecmd tcsh autoinit`
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
How do I run .fish files inside the function folder in my directory?
If you have fish shell installed and your default shell is sh/bash you can do it simply with
/usr/bin/env fish /path/to/script.fish
That works both in command line or in bash scripts.
Alternatively you can change to fish shell from you default one and execute it from there.
To explain what the command means:
/usr/bin/env fish - will locate fish executable based on your current environment PATH. After locating it it will be executed with all input after this line being passed as arguments to fish executable.
As another option you could simply find where your fish executable is and use /path/to/fish /path/to/script.fish
Third option would be to use hash-bang declaration in your script as first line #!/usr/bin/env fish and then make script executable (chmod +x /path/to/script.fish) so that your current shell would see that it needs to execute script with specified binary.
Lets say I have this bash script (test):
#!/usr/bin/env bash
source ~/.zshrc
In my .zshrc, I have the following:
autoload -U compinit
compinit
When I try and run 'bash test' from my terminal window (zsh), I get errors saying autoload and compinit commands are not found. If I just do source ~/.zshrc from the command line, it works fine.
I am trying to setup my development environment, similar to this blog, but when the scripts try and source the .zshrc file it fails.
Any insight would be appreciated.
In your script, you're using bash to run a zsh script. You might as well ask the python interpreter to parse perl.
Either change bash to zsh in the shebang line or write the script with bash commands.
It's not quite as bad as python vs. perl. Both bash and zsh are derived from the Bourne shell (whose behavior is standardized by POSIX), so any script designed to work with /bin/sh is likely to work with either bash or zsh.
Normally your ~/.zshrc, as the name implies, is designed to be used with zsh, and will typically include zsh-specific commands like autoload and compinit.
You can make those commands conditional, for example:
if [ "$ZSH_VERSION" ] ; then
autoload -U compinit
compinit
fi
But of course that means you won't get the functionality of those commands, unless you can figure out a way to emulate them in bash. (I'm not familiar with either command, so I can't help you there.)
(Note that this will fail if you've done set -u or set -o nounset in your bash shell.)
But if you're going to be using both zsh and bash, it probably makes a lot more sense to have separate ~/.bashrc and ~/.zshrc files, and use each one only with the shell for which it's designed. If you want to avoid duplication, each one can source a third file containing common commands.
(And based on the comments, it's likely you're doing the wrong thing in the first place.)
I tried activating a VirtualEnv through a shell script like the one below but it doesn't seem to work,
#!/bin/sh
source ~/.virtualenvs/pinax-env/bin/activate
I get the following error
$ sh virtualenv_activate.sh
virtualenv_activate.sh: 2: source: not found
but if I enter the same command on terminal it seems to work
$ source ~/.virtualenvs/pinax-env/bin/activate
(pinax-env)gautam#Aspirebuntu:$
So I changed the shell script to
#!/bin/bash
source ~/.virtualenvs/pinax-env/bin/activate
as suggested and used
$ bash virtualenv_activate.sh
gautam#Aspirebuntu:$
to run the script .
That doesn't throw an error but neither does that activate the virtual env
So any suggestion on how to solve this problem ?
PS : I am using Ubuntu 11.04
TLDR
Must run the .sh script with source instead of the script solely
source your-script.sh
and not
your-script.sh
Details
sh is not the same as bash (although some systems simply link sh to bash, so running sh actually runs bash). You can think of sh as a watered down version of bash. One thing that bash has that sh does not is the "source" command. This is why you're getting that error... source runs fine in your bash shell. But when you start your script using sh, you run the script in an shell in a subprocess. Since that script is running in sh, "source" is not found.
The solution is to run the script in bash instead. Change the first line to...
#!/bin/bash
Then run with...
./virtualenv_activate.sh
...or...
/bin/bash virtualenv_activate.sh
Edit:
If you want the activation of the virtualenv to change the shell that you call the script from, you need to use the "source" or "dot operator". This ensures that the script is run in the current shell (and therefore changes the current environment)...
source virtualenv_activate.sh
...or...
. virtualenv_activate.sh
As a side note, this is why virtualenv always says you need to use "source" to run it's activate script.
source is an builtin shell command in bash, and is not available in sh. If i remember correctly then virtual env does a lot of path and environment variables manipulation. Even running it as bash virtualenv_blah.sh wont work since this will simply create the environment inside the sub-shell.
Try . virtualenv_activate.sh or source virtualenv_activate.sh this basically gets the script to run in your current environment and all the environment variables modified by virtualenv's activate will be available.
HTH.
Edit: Here is a link that might help - http://ss64.com/bash/period.html
On Mac OS X your proposals seems not working.
I have done it this way. I'am not very happy with solution, but share it anyway here and hope, that maybe somebody will suggest the better one:
In activate.sh I have
echo 'source /Users/andi/.virtualenvs/data_science/bin/activate'
I give execution permissions by: chmod +x activate.sh
And I execute this way:
`./activate.sh`
Notice that there are paranthesis in form of ASCII code 96 = ` ( Grave accent )
For me best way work as below.
Create start-my-py-software.sh and pest below code
#!/bin/bash
source "/home/snippetbucket.com/source/AIML-Server-CloudPlatform/bin/activate"
python --version
python /home/snippetbucket.com/source/AIML-Server-CloudPlatform/main.py
Give file permission to run like below.
chmod +x start-my-py-software.sh
Now run like below
.start-my-py-software.sh
and that's it, start my python based server or any other code.
ubuntu #18.0
In my case, Ubuntu 16.04, the methods above didn't worked well or it needs much works.
I just made a link of 'activate' script file and copy it to home folder(or $PATH accessible folder) and renamed it simple one like 'actai'.
Then in a terminal, just call 'source actai'. It worked!
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 =)