I am trying to execute unix command using SSH from cygwin. My set of command would navigate to a certain directory, source a particular file. Based on the variables sourced from that file, I would try to launch application. But somehow the variables are not getting sourced as echo does not return any values. Could someone let me know what am I missing here
Contents of the environment variables file (myenv) are
export TEST_DATA="DATA1:DATA2"
and I am executing the following command
$ ssh kunal#kspace "ls; cd /disk1/kunal/env; . ./myenv; echo $TEST_DATA; "
Double quotes do not inhibit expansion. Use single quotes instead.
That is, the variable is being expanded on your side, not on the server you're SSHing to.
Because $TEST_DATA is in double quotes, its value is being interpolated by your local shell (the one you called ssh in). If you use single quotes it will pass the literal $TEST_DATA across as part of the ssh command to be executed on the far side.
Related
I looked up the forum but didn't find an article which matches my problem. Maybe there is some, and you can help me out with it.
My problem is I want to sync an folder with the command rsync -a -v. The point is I got 5 different Maschinen. On every maschine is a scratch folder I want to sync into the folder: ~/work_dir/scratch_maschines and inside the /scratch_maschines folder should be a folder for maschine_a, maschine_b and so on.
On the maschines it is always the same path: /scratch/my_name. So when I use now this command for the first two maschines:
rsync -a -v --exclude='*.chk' --exclude='*.rwf' --exclude='*.fchk' --delete sp02:/scratch/my_name ~/work_dir/scratch_maschine01; rsync -a -v --exclude='*.chk' --exclude='*.rwf' --exclude='*.fchk' --delete maschine02:/scratch/my_name ~/work_dir/scratch_maschine02
I got a folders for scratch_maschine01 and scratch_maschine02 in my working directory but inside these folders are not direct my data there is first a folder inside with my_name and this folder contains the data. So my question is how can I use the rsync command and get the files from the scratch directorys straight to the folders for each machine?
You might want to consider reformulating your commands similar to the following:
START=`pwd`
EXCLUDES="--exclude='*.chk' --exclude='*.rwf' --exclude='*.fchk'"
{ SOURCE="sp02:/scratch/my_name"
REMOTE="${HOME}/work_dir/scratch_maschine01"
cd "${SOURCE}"
rsync --recursive -v --delete ${EXCLUDES} "./" "${REMOTE}/"
}>${START}/job.log 2>${START}/job.err
The key elements there are
the --recursive which will rsync will expand to include all content and subdirs of the SOURCE directory.
the / behind the ${SOURCE} notifies rsync to limit itself to content of the SOURCE directory, but not the directory itself.
the / behind the ${REMOTE} notifies rsync to limit itself to depositing content into that directory and expect it to already exist, to specifically fail if that does not already exist at REMOTE; this ensures that the remote site doesn't attempt a failsafe PWD and deposit files elsewhere than expected.
The above approach lends itself to a function form that could be placed into a loop with pre-attempt condition checks, along with having a complementary case for all variable assignments grouped under a destination heading (i.e. case statements).
Using such an approach with meaningful labels for variables lends itself to a type of implicit documentation, making the code more meaningful to someone not familiar with the code, as well as a refresher for yourself after a long period of not working or using the code.
I try to avoid the "~" because I prefer to always enclose definitions for variables in double quotes, to avoid issues that might arise from paths that may include unexpected characters or spaces. That way, you are sure to have your defined paths correctly interpreted by commands in scripts.
Lastly, I prefer to use the long form for the rsync options (and almost every other command) so that I don't have to refer to the manual every time to translate the single-character options when trying to understand what is coded, if the need arises for troubleshooting unexpected errors (I have always had poor memory).
My own backup command is as follows. The only reason why the
${PathMirror}${dirC}/
is not encapsulated in single quotes within the double quotes for COM is because I know those variables all evaluate to non-complex strings which cannot be misinterpreted.
I have a file loaded in R that I want to move to a samba share
It is something like
write(some-file, file = "|smbclient -U user //ip password")
It connects to the samba but then (I think) the output is "executed" in the smb: \> and I don't want the file to be executed, I don't know how to pass the file to the destination with a putfunction inside smbclient.
Edit: This is not the same problem as the first post. The first post is solved and answered by me. The point there was connecting to samba. Now I'm already connected to it but the write() function doesn't make a file, instead it pipes out the words separately. I just wanted to know how to make it create a file in a sentence.
I found the answer by changing the philosophy:
First, I write the file locally, like
write(some-file, there)
Then I use the system() function to call smbclient and put the file already written
system("smbclient -U user //ip/dir password -c \"put some-file some-file\"")
My script is more complex and it's inside a Shiny app but in summary that's the solution
I have a bunch of customizations and would like to run my test program in a pristine environment.
Sure I could use a tiny shell script to wrap and pass of arguments but it would be cool and useful if I could invoke a pre and possibly post script only to commands located under certain sub directories. The shell I'm using is zsh.
I don't know what you include in your “pristine environment”.
If you want to isolate yourself from the whole system, then maybe chroot is what you're after. You can set up a complete new system, with its own /etc, /bin and so on, but sharing the kernel, networking and other non-filesystem stuff with your running system. Root's cooperation is required (the chroot system call is reserved to root).
If you want to isolate yourself from your dot files, run the program with a different value for the HOME environment variable:
HOME=~/test-environment /path/to/test-program
HOME=~/test-environment zsh
If this is specifically about zsh's configuration files, you can set the ZDOTDIR environment variable before starting it to tell zsh to run its own dot files from a directory other than $HOME (or zsh --no-rcs to not load any dot file).
If by pristine environment you mean a fully controlled set of environment variables, then the env program does this.
env -i PATH=$PATH HOME=$HOME program args
will run program args with only the environment variables you specified.
I am trying to convert a PDF document into a PNG file using ImageMagick command line tools from a ASP.NET website. I create a new shell process and ahve it execute the following command:
convert -density 96x96 "[FileNameAndPath].pdf" "[FileNameAndPath].png"
This runs well when testing the website on my local machine with the ASP.NET Develeopment Server of VS and the command also works well when manually entered into the shell. When running from the programatically created shell in ASP.NET there is the following error message:
Invalid Parameter - 96x96
Does anybody know why that happens and what to do?
I have tested the command while being logged in on the server via RDP with a different user account than the ASP.NET process. I have used exactly the same ImageMagick and Ghostscript installation files as on my local machine and have activated adding the ImageMagick installation path to the enironment variables during installing. The server has not been rebooted since than.
convert is also the name of a windows executable which converts FAT filesystem to NTFS. When you do not specify the full path of an executable, quote:
...the system first searches the current working directory and then
searches the path environment variable, examining each
directory from left to right, looking for an executable filename that
matches the command name given.
"C:\Windows\System32" is generally present in the beginning of %PATH% variable, causing the Windows convert utility to launch, which fails with "Invalid Parameter" error as expected.
Try specifying the full path of the ImageMagick's convert.exe like so:
"C:\Program Files\ImageMagick\convert.exe" -density 96x96 "path_and_filename.pdf" "path_and_filename.png"
As others have stated convert points to a different program in your PATH. Instead preface your command with magick. So your command would instead be:
magick convert -density 96x96 "[FileNameAndPath].pdf" "[FileNameAndPath].png"
In Window actually exists a "convert.exe" in system32 - make sure your script doesn't start that one (maybe the environment paths on your development machine are set differently).
I am only answering this late because imagemagick was updated. Now, if you wish to use the "convert" command, you do it like this:
magick convert "image.png" "document.pdf"
or
magick convert "image_00*.png" "document.pdf"
for multiple images.
Same syntax for command, just add magick before it
A couple more options for fixing this:
Edit your Path system variable to contain the path to imagemagick
as it's first content and then add the rest after it. This will make
windows always find the imagemagic convert first before it finds
the other convert program. So something like this: C:\Program Files\ImageMagick-6.9.2-Q16;C:\Program Files\Haskell Platform\2014.2.0.0\lib\extralibs\bin;...
Another option is to create a dedicated folder somewhere on your machine where you will place shortcuts for some of these name clashes. Then what you do is that you rename those shortcuts to meaningful names, for example convert_image_magick, then add the path to this folder to your system path. So now as you hit tab more, you will finally find the right program you want to run
yes! if you launch an Administrator command window it defaults to C:\windows\sytem32\ ... as long as you're not in that directory the command will pickup the ImageMagick convert.exe
My issue was I was using the "FORFILES" command which is tricky because it requires using
"cmd /c" and passing the convert command with #path and #file parameters and it does some escaping of slashes... needless to say it's caused me hours and hours of headache. It even parses hex characters, like if your filepath has the combination 0x00 in it, it will think that's a hex value and mangle your path. I had a filepath named C:\ImageRes3000x3000
and FORFILES interprets that literally and it caused a strange path issue. Sorry if this is a long useless post but it's meant to be FYI, if someone runs across this, maybe it will help them. That being said, FORFILES and "convert.exe" are a powerful and simple image renaming line script combo.
here's my full 3 line image renaming script
robocopy D:\SRC_DIR\ D:\DEST_DIR\_staging *.jpg /e /MAXAGE:2
FORFILES /P D:\DEST_DIR\_staging\ /S /M *.jpg /C "cmd /c convert.exe #path -quality 65 -resize 1500 D:\RESIZED_DIR\\#file"
DEL D:\DEST_DIR\_staging\*.* /S /Q
At a unix command line, what's the difference between executing a program by simply typing it's name, vs. executing a program by typing a . (dot) followed by the program name? e.g.:
runme
vs.
. runme
. name sources the file called name into the current shell. So if a file contains this
A=hello
Then if you sources that, afterwards you can refer to a variable called A which will contain hello. But if you execute the file (given proper execution rights and #!/interpreterline), then such things won't work, since the variable and other things that script sets will only affects its subshell it is run in.
Sourcing a binary file will not make any sense: Shell wouldn't know how to interpret the binary stuff (remember it inserts the things appearing in that file into the current shell - much like the good old #include <file> mechanism in C). Example:
head -c 10 /dev/urandom > foo.sh; . foo.sh # don't do this at home!
bash: �ǻD$�/�: file or directory not found
Executing a binary file, however, does make a lot of sense, of course. So normally you want to just name the file you want to execute, and in special cases, like the A=hello case above, you want to source a file.
Using "source" or "." causes the commands to run in the current process. Running the script as an executable gives it its own process.
This matters most if you are trying to set environment variable in current shell (which you can't do in a separate process) or want to abort the script without aborting your shell (which you can only do in a separate process).
The first executes the command. The second is shorthand for including a shell script inside another.
This syntax is used to "load" and parse a script. It's most useful when you have a script that has common functionality to a bunch of other scripts, and you can just "dot include" it. See http://tldp.org/LDP/abs/html/internal.html for details (scroll down to the "dot" command).
Running "runme" will create a new process which will go on its merry little way and not affect your shell.
Running ". runme" will allow the script "runme" to change your environment variables, change directories, and all sorts of other things that you might want it to do for you. It can only do this because it's being interpreted by the shell process that's already running for you. As a consequence, if you're running bash as your login shell, you can only use the "." notation with a bash script, not (for example) a binary on C shell script.