No matter what I try, executing pwd always prints /var/log/rundeck. I'd like to configure this as a global or even project-wide setting as all my scripts and commands will be relative to a specific directory on the file system.
/home/jobs for example.
There is no setting on Rundeck can set working directory.
Each command is running in separate context, you can chain them together.
As an improvement to the above answer by "Yang" you can edit rundeck "resources.xml" file and add a attribute called "nodepwd" with your node location like below.
<node name="localhost" nodepwd="/your/pwd/location" .... />
Then you can change your path to that and execute the commands.
In my case, I have to run "cd $RD_NODE_NODEPWD" in my inline scripts to change the current working directory.
Related
I am trying to configure dymola.mos file, here is an example of changing directory, but when I activate Dymola, it seems the working directory doesn't change at all, even though the log shows Dymola run the script.
My question is:
How could I make the cd command work in the dymola.mos file?
I assume you have activated the option Save startup directory. You can check this with the flag Advanced.StartupDirectory, which will be either 1 or 2. You can simply turn that off or follow the steps below.
From your command log we see that:
Dymola first executes the script <install-path/insert/dymola.mos
Then it restores the settings stored in setup.dymx
Hence the settings in setup.dymx override your working directory.
Instead of using <install-path/insert/dymola.mos you should use a custom .mos script, which is passed as first argument to dymola.exe on startup. This will always be executed last.
Example for Windows
Create the file startup.mos somewhere, e.g. in C:\dymola\startup.mos
Create a shortcut to Dymola.exe, (for Dymola 2021x: C:\Program Files\Dymola 2021x\bin64\Dymola.exe)
Add the .mos script as argument in the Target field in the properties of the shortcut. The result will be:
"C:\Program Files\Dymola 2021x\bin64\Dymola.exe" "C:\dymola\startup.mos"
I have changed the shell key in windows registry to gain custom shell (Kiosk usage):
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon]
I set shell key to a batch file which runs two applications as below:
start "myFirstAppTitle" "myAppPath\myApp1.exe"
start "mySecondAppTitle" "myAppPath\myApp2.exe"
Each application runs but the second application which needs some files to be excuted throws an error which says could not find dependency files. whereas the dependency files are adjoining to the exe file and the mentioned app works fine, when starts from startup.
Meanwhile when i run the batch file manually it rusn fine.
I added the PATH command to the batch file but it did't work too.
Change the batch file to this:
set PATH=%PATH%;C:\MyAppPath
start "myFirstAppTitle" "myApp1.exe"
start "mySecondAppTitle" "myApp2.exe"
If you start executables without an absolute path, the path is relative to the current working directory. Also, when you specify an executable with a relative path, %PATH% is not searched for a matching subfolder with a matching executable.
Since the script worked when you manually started it, your working directory probably was C:\. However, when run at logon as a replacement shell, the working directory is most likely "%SystemRoot%\system32".
The problem solved strangely, i removed the title parameter of start command and it worked. In fact i used start command this fashion:
set PATH=%PATH%;C:\MyAppPath
start myapp.exe
start myapp2.exe
I'm trying to set an environment variable in a build script with phing.
This is normally done command line like this:
export MY_VAR=value
In Phing I did the following but it isn't working.
<exec command="export MY_VAR=value" />
I see that this is quite an old question, but I don't think it has been answered in the best way. If you wish to export a shell variable, for example say you are running phpunit from phing and want to do an export before invoking phpunit, try:
<exec command="export MY_VAR=value ; /path/to/phpunit" />
Simply do the export and invoke your command inside the same exec tag. Separate the export statement and the shell executable with a semicolon as shown. Your script will be able to access the value using the standard php function:
$myVar = getenv('MY_VAR');
Bold claim: There is no way to set/export a (Unix) shell variable in PHP so that it is visible inside the scope that started the php script.
php myfile.php (does putenv or shell_exec('export foo=bar');)
echo $foo
Will return nothing.
As PHP can not do it so neither can phing.
Accessing shell environment variables accross multiple script runs (if its that what you want) seems also like an unideal design decision, pretty stateful.
Apart from that I'd urge you to stick to phing and learn its lean lesson. Phing helps stateless thinking to some degree.
I'd never heard of phing before, but this looks very promising as a build tool. Thanks for posting! I looked through the doc on phing.info, I found the following possibility:
#0 I would like to clarify one point. Are you saying that
prompt$ > export MY_VAR=value
prompt$ > phing build.xml
doesn't set MY_VAR to value so it is visible inside the running phing processes? I'd be surprised, but I would understand if this is not how you want to run your build script.
#1 I think in the context of a build tool, a feature like exec is meant to run a stand-alone program, so, while the exec may run and set MY_VAR, this is all happening in a subprocess that disappears immediately as the exec finishes and continues processing the next task in the build.xml.
If you're just trying to ensure that your phing script runs with specific values for env_vars, you could try
Command-line arguments:
....
-D<property>=<value>
// Set the property to the specified value to be used in the buildfile
So presumably, you can do
phing -DMY_VAR=value build.xml
#2 did you consider using a properites file?
See http://www.phing.info/docs/guide/stable/chapters/appendixes/AppendixF-FileFormats.html
and scroll down for info on build.properties
#3 also ...
Phing Built-In Properties
Property Contents
env.* Environment variables, extracted from $_SERVER.
you would access them with something like
${env.MY_VAR}
#4 This looks closer to what you really want
<replacetokens>
<token key="BC_PATH" value="${top.builddir}/"/>
<token key="BC_PATH_USER" value="${top.builddir}/testsite/user/${lang}/"/>
</replacetokens>
I hope this helps.
I have a perl script (which syncs delicious to wp) which:
runs via the shell but
does not run via cron (and i dont get an error)
The only thing I can think of is that it read the config file wrongly but... it is defined via the full path (i think).
I read my config file as:
my $config = Config::Simple->import_from('/home/12345/data/scripts/delicious/wpds.ini',
\my %config);
(I am hosted on mediatemple)
Does anybody have a clue?
update 1: HERE is the complete code: http://plugins.svn.wordpress.org/wordpress-23-compatible-wordpress-delicious-daily-synchronization-script/trunk/ (but I have added the path as above to the configuration file location as difference)
update 2: crossposted on https://forums.mediatemple.net/viewtopic.php?pid=31563#p31563
update 3: the full path did the trick, solved
The difference between a cron job and a job run from the shell is 'environment'. The primary difference is that your profile and the like are not run for a cron job, so any environment variables you have set in your normal shell environment are not set the same in the cron environment - no extensions to PATH, no environment variables identifying where Delicious and/or WP are hosted, etc.
Suggestion: create a cron job that simply reports the environment to a known file:
env > /home/27632/tmp/env.27632
Then see what is set in your own shell environment in comparison. Chances are, that will reveal the trouble.
Failing that, other environmental differences are that a cron job has no terminal, and has /dev/null for input and output - so interactive stuff does not work well.
it seems the problem is not in running perl, but locating the Config library
you should try:
perl -e "print #INC"
and run a similar perl script in cron, and read the output
it possible that they differ
I suggest looking at my answer to How to simulate the environment cron executes a script with?
This is an similar Jonathan's answer but goes a bit further.
Based on your crontab, and depending on your installation, the problem might be the "perl". As others note the environment, particularly the $PATH variable, is different for cron. perl may not be in the path so you need to put the full path to perl in the cron command.
You can determine the path with the command $ type perl
I run into the same problem ...
Perl script works but not via CRON => error: "perl: command not found"
... after an update from Plesk 12.0 to Plesk 12.5. But the existing answers were not very helpful for me.
It took some time, but than I found this thread in the Odin forum which helps me: https://talk.plesk.com/threads/scheduled-tasks-always-fail.331821/
They suggest the following:
/usr/local/psa/bin/server_pref -u -crontab-secure-shell ""
That deletes in the /var/spool/cron/crontabs files the line:
SHELL="/opt/psa/bin/chrootsh"
After that, my cron jobs run with out any error.
(Ubuntu 14.04 with Plesk 12.5)
If the perl script runs fine manually, but not from crontab, then
there is some environment path needed by the some package that is not
getting through `cron`. Run your command as follows:
suppose your cron entry like:
* 13 * * * /usr/bin/perl /home/username/public_html/cron.pl >/dev/null 2>&1
env - /home/username/public_html/cron.pl
The output will show you the missing package. export that package path in
$PATH variables
On windows systems, certain dos commands don't have executables that can be explicitly called via NAnt's exec task. (I'm talking specifically about commands that are part of Command.com)
A complete list can be found here. While some of the more useful commands can be achieved with NAnt or NAntContrib tasks (copy, move, rename etc), some (such as 'type') cannot.
How can you execute these commands as part of a build? For example, using a wildcard, how can I easliy display the contents of a log file from an external command executed by my build (so that the external command's log file contents will become echoed into the build's log file)
Internal commands can be called using the exec task in the following manner :
<exec workingdir="${dir}" program="cmd" commandline="/c <command/> <arguments/>" />
For the scenario in the question (where the log's filename is based on the current time, partway through the build), rather than parsing/scanning for the filename, loading it into a property and then echoing it, you could echo log contents with the following task :
<exec program="cmd" workingdir="${dir}" commandline="/c type *.log" />