When I submit a job with qsub to SGE, the job's shell will not read .bashrc. Is there a file analogous to .bashrc that will be read by the shell of all jobs started with qsub?
I know there is a .sge_request file, but it only contains default options for qsub, not a list of commands like .bashrc. What I want is to set some environment variables for my job, like $PATH and $LD_LIBRARY_PATH. I don't think I can do that with .sge_request, but if I can, that would also solve my problem.
This is better accomplished using the -V option to qsub , which imports all environment variables set, including those in .bashrc.
.bashrc can be read if you submit an interactive job, just change the header of your job script to:
#!/bin/bash -i
Related
I have a bash script that finds and exports emacs .org files to html in a given directory. I understand that org-mode makes use of htmlize.el to color the output of text in SRC blocks, which seems to work fine when executed from the command line, both as root and normal user. However, when using systemd timers to automate this task the output is no longer colored.
for i in `find /home/user/dir -name '*.org'`
do
emacs $i --batch -l /home/user/.emacs org-html-export-to-html --kill
done
I previously had problems with getting the syntax highlighting to work when executing the script directly, which was solved when -l /home/user/.emacs was added as shown in the excerpt above (publishNotes.sh).
Everything apart from the syntax highlighting seems to be working fine, which indicates that both the systemd service and the executed script itself runs according to the timer.
Service:
[Unit]
Description=Update website
[Service]
Type=simple
ExecStart=/home/user/bin/publishNotes.sh
Timer:
[Unit]
Description=Run every hour
[Timer]
OnCalendar=hourly
Unit=publishNotes.service
[Install]
WantedBy=multi-user.target
Thanks!
I would guess that this is because something is loading differently when run as root than when run under your user account. Exactly what is hard to say from the information given. However, my first suggestion would be to try running the service as your user. Try adding the User=<username> key to the [Service] section of the service, and check to see if it behaves as you expect.
When you build Tcl/Tk by default it creates the files
tclsh85
wish85
However many programs call tclsh and wish. This is one fix for that
cp tclsh85 tclsh
cp wish85 wish
However, can you simply build tclsh and wish directly, perhaps using a configure argument?
This behavior is The Right Thing as it allows several versions of the interpreter and its libraries to coexist in the system. The system, in turn, does provide a way to "bless" one of the version as "default" — for instance, Debian provides "alternatives". In essence, usually a symlink with the "canonical" name is created pointing to the real executable, like /usr/bin/tclsh → /usr/bin/tclsh85. And with the "blessed" version available via such a symlink for the applications that do not care about the precise version of the runtime, certain other applications still can pick some specific runtime version by referring to the interpreter's real executable name.
This also provides an easy way to test an existing program against an experimental runtime version: you just run /usr/bin/tclsh86 /path/to/the/script.tcl instead of just running /path/to/the/script.tcl as usually which relies on the shebang to pick the interpreter.
A long time ago, the builds of Tcl and Tk used to work in the way you describe. It was changed to the current system (putting the version number in the name) to allow multiple versions to coexist more smoothly; this was a very strong demand from the user community at the time.
Symlink the version-less filenames to the real ones (or use the mechanism of your distribution) if you want to give up control over which version to use. Alternatively, use this (fairly horrible) piece of mixed shell/Tcl code at the top of your files:
#!/bin/sh
# Try with a versionless name \
exec tclsh "$0" ${1+"$#"}
# Otherwise, try with tclsh8.6 \
exec tclsh8.6 "$0" ${1+"$#"}
# Otherwise, try with tclsh8.5 \
exec tclsh8.5 "$0" ${1+"$#"}
# Otherwise, try with tclsh8.4 \
exec tclsh8.4 "$0" ${1+"$#"}
# Otherwise... well... give up! \
echo "no suitable Tcl interpreter" >&1; exit 1
This relies on the fact that Tcl, unlike the Unix shell, treats a \ at the end of a comment line as meaning that the comment extends onto the next line.
(Myself? I don't usually put in #! lines these days; I don't consider it an imposition to write tclsh8.5 myscript.tcl.)
I noticed that I can't combine --traditional options with the other one letter other options such as -i for example.
For example, when I have this as the first line in my octave .m file
#!/usr/bin/octave --traditional
Then it work. Octave starts ok and runs the script.
But when I try
#!/usr/bin/octave --traditional --silent --norc --interactive
It does not work. Error from octave. does not understand the options.
When I try
#!/usr/bin/octave --traditional -qfi
Also error. But this
#!/usr/bin/octave -qfi
works.
The problem is that --traditional does not have a one letter short cut like all the other options. This is the options I see
Options:
--debug, -d Enter parser debugging mode.
--doc-cache-file FILE Use doc cache file FILE.
--echo-commands, -x Echo commands as they are executed.
--eval CODE Evaluate CODE. Exit when done unless --persist.
--exec-path PATH Set path for executing subprograms.
--help, -h, -? Print short help message and exit.
--image-path PATH Add PATH to head of image search path.
--info-file FILE Use top-level info file FILE.
--info-program PROGRAM Use PROGRAM for reading info files.
--interactive, -i Force interactive behavior.
--line-editing Force readline use for command-line editing.
--no-history, -H Don't save commands to the history list
--no-init-file Don't read the ~/.octaverc or .octaverc files.
--no-init-path Don't initialize function search path.
--no-line-editing Don't use readline for command-line editing.
--no-site-file Don't read the site-wide octaverc file.
--no-window-system Disable window system, including graphics.
--norc, -f Don't read any initialization files.
--path PATH, -p PATH Add PATH to head of function search path.
--persist Go interactive after --eval or reading from FILE.
--silent, -q Don't print message at startup.
--traditional Set variables for closer MATLAB compatibility.
--verbose, -V Enable verbose output in some cases.
--version, -v Print version number and exit.
I am mainly interested in running octave code that is compatible with Matlab, so I'd like to use this --traditional option to make sure I keep the code compatible with Matlab in case I need to run the same code inside Matlab as well.
Or may be I can "turn on" this compatiblity mode once octave starts using a different command?
I am using GNU Octave, version 3.2.4 on Linux.
thanks
I don't think this is really an octave problem, per se. The Unix shebang notation in general is somewhat limited. I don't know the exact limits off the top of my head, but I'm pretty sure many implementations aren't happy if you add more than one option to the shebang line, which seems to be your problem.
Using a wrapper script is probably the canonical way to get around such problems.
To address your question of combining short and long options, Unix conventions don't allow for this. You could consider patching octave to add a short option for --traditional, if this is feasible for you. Alternatively, I'd imagine there's a way to specify the traditional behavior in the user or system-wide Octave configuration file, but this might not be that helpful if you need the script to work on systems you don't control.
I would like to have a shell script that copies some logs from a part of my system to the hudson workspace so I can archive them.
So right now I have
#!/bin/bash -ex
cp /directory/structure/*.log .
This is kind enough to be changed to
cp '/directory/structure/*.log' .
Which of course is not found since I don't have a file named *.log.
So how do I get this script to work?
EDIT
So I left out the part that I was using sudo cp /path/*.log, because I didn't think that would matter. Of course it does and sudo is the issue not hudson.
One simple answer would be to have the shell script in a separate file, and have hudson call that.
sudo bash -c "cp /directory/structure/*.log"
Throwing it out there, but haven't had a chance to try it in Hudson (so I don't know how it gets quoted):
for f in /directory/structure/*.log ; do
cp $f .
done
In my simple test in a bash shell, different quoting options produce either one or multiple invocations of the copy command (either with all matching files or one at a time), but they all manage to do the copy successfully.
I have a tcl script which 'exec' rpmbuild. When doing so, the 'topdir' used by rpmbuild is wrong. I have a .rpmmacros file in my home directory and if I call manually rpmbuild, it works fine, ie. the 'topdir' is not the default one.
I added a [exec rpmbuild "--showrc" ] in the tcl script to check the value of topdir and it says '-14: _topdir %{_usrsrc}/redhat' which is the default value.
Can someone explain me why is that situation and how to solve it ?
I would prefer not to have to specify it with --define because it is actually done in a makefile and I don't want to touch it (if no other choice, I will do it).
There's two ways to change the default rpmbuild topdir:
Per-User: By configuring the RPM topdir in $HOME/.rpmmacros
%_topdir %{getenv:HOME}/rpmbuild
Per-Project: By configuring the RPM topdir in the Makefile or on the command line
rpmbuild --define '_topdir build' -ba package.spec
Note: in both cases, you will need to make sure your topdir directory has the appropriate directories (BUILD, SRPM, RPM, SPECS and SOURCES)
In RHEL6 do:
rpm --showrc|grep topdir
rpm --showrc|grep srcrpmdir
To see what are the paths being used !
Make this change (my topdir was NOT set to /usr/src/):
vi /usr/lib/rpm/macros
# Path to top of build area.
#%_topdir %{getenv:HOME}/rpmbuild
%_topdir %{_usrsrc}/redhat
rpm --showrc|grep topdir now shows /usr/src/redhat/ as its BUILD dir
TCL will exec in the current directory by default. You can change the current directory by using the TCL command http://www.tcl.tk/man/tcl8.4/TclCmd/cd.htm cd, for example:
cd ~username
If topdir is an environment variable, you might be able to set it http://www.tcl.tk/man/tcl8.4/TclCmd/tclvars.htm#M4 like this:
set env(topdir) whatever/you/want
My first check would be to make sure you execute the same thing.
Do these two on the command line to make sure aliases or paths
do not disturb anything.
which rpmbuild
echo 'puts [auto_execok rpmbuild]' | tclsh
In my case, this is due to the variable $HOME which is not set when rpmbuild is called.The variable is used to search the '/rpmmacros' file. I suggest to use the command 'printenv' to verify.