When you run an executable that resides on a network path relative to the machine you are using, for example, \\networkmachine\folder\target.exe arg1 arg2, I know that it is executed locally, but does anyone know if the command line arguments end up getting passed across the network connection?
Ofcourse not. Start thinking on the lines how your binary which sits in network location gets executed in local machine. When you execute the command, the immideate task which is responsible for command execution (in Linux shell, in windows I don't know what) take whole command you typed in as its argument parse it to understand that it is an instruction to execute an executable and the first argument is the name of the executable the next arguments are the arguments to be passed to it. Then it tries to start the execution, in Linux it does fork() and then exec(). Basically, try to load the executable on memory and then keeps the arguments in place before start of execution. To load the executable to memory, it has to read the executable and this is the time it will try to read the executable file, and this is exactly the time it will do the network operation (in your case) or disk read operation if it is in disk. If it is in Linux, and NFS sort of network hosted file, network operation will again go down one more layer as the loader does a regular file read and the NFS layer does the necessary network operation to make the data available. There is no point in this sequence where you have to send the arguments through network.
So, to sum it up the arguments are never send across the network.
Related
I am looking for a strategy suggestion.
I am very new to Linux shell scripting. Just learning tcsh not more than a month.
I need a script to automatically detects when is the result files are done copied back from a remote server to a folder in a remote machine, then start scp the files back to my workstation.
I do not know in advance when the job will finish run, so the folder could have no result files for a long while. I also do not know when will the last result file done copied back from remote server to the folder (and thus can start the scp).
I had tried crontab. Work fine when I guess correctly, most of the time just disappointing.
So I tried to write a script myself and I have it now. I intend to produce a script that serves me and my colleagues too.
To use the script, the user first need to login to the remote machine manually. Then only execute the script at remote machine. The script first asks for user to input their local machine name and directory where they wish to save the result files.
Then the script will just looping to test when is the total number of files change. When it detected that, which means the first result file is starting to be copied back from the remote server, then it loops again to detect when is the total files size in the folder stop changing, which means last result file is finished copied to the folder. After that it executes scp to send all the result files to the user workstation, at the initially specified directory.
Script works fine but I wish to make the script able to run in background and still running by itself even if the user logout from the remote machine and close the terminal. And also I wish to let the user just type in a simple command in terminal to start the script, something like a simple
./script.tcsh
I tried to run the script by command
./script.tcsh &
but fails, because background process unable to accept user input.
Google and found something called disown, but the command is not found. Apparently the remote machine and my machine does not support this command.
Tried to modify the script to first accept the user input, then attempt to use
cat > temp_script.tcsh << EOF
{rest of my script}
EOF
and then a line of
./temp_script.tcsh &
to try to create another script file and use the first script to initiate the second script in background. Also fail, because cat does not treat $variable as a literal text, it replaces it with values. I have a foreach i(1 2) loop, and the cat command just keep reporting error (missing value of variable i, which is just a counter in foreach loop syntax).
I am out of idea at the moment.
Can anyone enlighten me with some strategy that I can try myself?
The goal is to use only 1 script file, and prompt user for 2 inputs (machine name and directory to save), then no more interaction with user or waiting, and able to run even closing the terminal.
Note: I do not need password to login to remote machine and back.
When compiling/interpreting a program from the command prompt, how does the command prompt know where to find the requested compiler/interpreter?
Are these files stored in a specific place or something like that? I'm just about getting a hang of high-level programming, but I find it pretty hard to wrap my head around what happens under the hood.
There are two parts: Where to find the file just from it's filename, and what to do with it.
Where files (programs) are searched if just the name is entered:
Windows (CMD):
There is a variable %PATH% which has a list of ;-separated directories, eg. C:\Windows;C:\Windows\system32;C.\somethingelse. It is saved somewhere in the registry and can be set either in CMD itself or with a GUI somewhere in the OS configs.
Linux etc. (Bash and many more):
Similar, there is a variable $PATH which can be set at least in the shell and various config files, and the entries are separated by :, eg. /bin:/usr/bin/even/more. Priority is from left to right.
Additionally, some shells (eg. Bash) cache lookup results in their own implementation-specific way (depending on the configuration), because it's faster than having to check every directory in the path variable (at least if the searched program is in the last dir, everything has to be checked).
What to do with the file once it's found:
Windows:
In Windows, everything works with the filename suffix.
.exe and some others are native programs to start.
.bat is a shell script which is executed like it's manually written to the shell.
For every other suffix, it's configurable which program belongs to the suffix (stored in the registry, how to comfortably change it depends heavily on the used Windows version). Eg. you could say that .py belongs to your Python interpreter, the a file foo.py will start the interpreter. Btw., the same suffix-program configuration is usen when a file is double-clicked in the GUI file explorer, and of course program installers can add their entries too without the user having to do it.
Linux:
For Linux, the suffix is not as important. The first relevant thing is a binary (yes/no) flag x (x like executable) which exists for each file on the file system, just like file name, creation timestamp etc.etc.
If the x flag is set to yes:
Linux tries to detect what kind of program it is from the content. The difference between a native compiled binary program and a not-compiled script of some scripting language is pretty clear.
A native linux program is started by the kernel, like expected. Additional binary program types could be configured, eg. there is the Wine software which runs some Windows programs on Linux, and one could add a specification how Windows exe`s can be recognized inside and that they should be started with Wine.
For a text file with the x flag, the next step is to look at the first line, which should start with a '#!' (called shebang), followed by the path of the interpreter (eg. #!/bin/bash). Shell scripts (like the bat files on Windows) are realized this way, but it's not limited to classical shell scripts: Nothing prevents anyone from making a #!/bin/python script which Python content (of course, Python has to be installed for this to work).
If the x flag is set to no:
Shells like bash with usual configuration won't do anything, independent if it is a real program just without flag or a jpg image etc. For the GUI file managers:
Again, the content (and possibly the file name suffix too) is inspected to get the type, like jpg images, mp3 music, C++ source code etc.etc. (Linux knows pretty many types), and then the fitting program is looked up in a list configurable by the user and/or program installations (mime file type id <-> program).
...
Note that in the case of eg. Python scripts (which are just normal text files, not something for the kernel to work with), it can be done with and without x flag: With flag and a shebang line, or without flag and a matching mime list entry. In the "without flag" case, the shebang won't hurt if it is there, because Python (and many other scripting languages) consider it a comment because of the #.
Regarding interpreters on unix-based systems, lots of scripts start with a so-called shebang or hashbang (#! on the first line of the script) that tells what interpreter to invoke, see https://en.wikipedia.org/wiki/Shebang_%28Unix%29 .
When you enter something like some-program some-arguments, the shell will look through each directory listed in the environment variable $PATH for an executable file named some-program (on Windows it's %PATH% and some-program.exe).
This is not specific to compilers and interpreters - it happens whether some-program is gcc, python, firefox or notepad.
In my Java program, I am using a command line library to fork a Java process. This fails (depending on how the program is used) when the file path of the JAR file that I pass in the java.exe -jar call exceeds the 260 character path length limit of Windows. (The error message is Error: Unable to access jarfile followed by the path name.) I can make the Java call work by (manually) adding a \\?\ prefix to the JAR file name. This solves the one particular problem instance, but is this generally the right approach?
Should I expect Windows programs to correctly handle long paths passed as command line arguments, - or - is it the caller's responsibility to detect long paths and to add the \\?\ prefix?
Or less general: Is there a bug in the java.exe or in the command line library?
Most programs will simply take the filename and pass it as-is to an API function, like CreateFile(). So in that case, it would indeed be the caller's responsibility to detect a long filename and prefix it accordingly before passing it around.
Short story: need a method to get the write-status of a file on a server (using BASH) from a client (using CMD batch).
Long-time lurker, first-time poster. I did many searches on variations of what I'm looking for and have not yet found enough data.
I am writing a batch file in CMD (because the clients could be any WinOS [XP - up] with unknown packages installed). The batch uses puTTY's "plink" to connect via SSH to the server. Once connected to the server, plink executes a command to write data to a new file.
Once that file is written, I use PSCP to copy the file to the client
So far, so good; I have successfully accomplished all of this.
The creation of that file is instantaneous but the time it takes to write all of the data is unknown / variable. Therefore I need an automated method to determine when the file is complete, to then copy it. Simply using timeout/sleep for XX seconds is not feasible in my circumstances.
The approach I have taken so far (as of yet unsuccessfully) is to repeatedly grab the filesize using "stat -c '%s' filemane" and run that in a loop until grab1 EQU grab2, indicating a complete file. I am finding this difficult because I can't get the output of stat into the CMD batch to process it.
Q1: Is this (stat result going into CMD for loop) the best approach? Maybe there's something existing in BASH?
Q2: if Q1 is true, any ideas on how to get the stat result into the CMD batch as a variable to parse/analyze the data?
Thanks in advance for suggestions and your time.
DCT
Have the command writing the file write it with a temp filename. So if it will be called xyz.txt, have it written with filename tmpxyz.txt.tmp, then the final step will be a rename.
That way you can just check for the presence of the named file.
Usually a good idea to give the file a unique name, probably incorporating the date and time, I find.
I have a Windows batch script that I use to build a module and the script in turn uses the ClearCase clearmake command to drive the actual compilations, directory creations and file manipulations, i.e. process the Makefile content. The batch script works flawlessly when invoked using a DOS window or from a "cmd /c ..." command line invocation. And it has been that way for some number of years.
I recently decided to move the script to Ant. The first step, out of simplicity, was to simply invoke the script unchanged using an Exec task (using cmd /c). Almost immediately, Ant fails while creating a directory. The error message reports something like:
mkdir: Cannot create the directory C:\\fred\\harry\\joe
I was able to verify that, using the DOS command prompt, the mkdir C:\\fred\\harry\\joe command works fine, so, as near as I can tell so far, Ant generating double backslash path separators combined with something inherent to clearmake and/or something in the Makefile is causing the failure.
The response I'm looking for is something along the lines: "Yes, clearmake is definitely the culprit because..." or "If you twiddle this thing or that thing in Ant, only a single backslash will be generated...". Should there be no simple and quick explanation, I will drill into the problem to determine what exactly is causing the failure.
Thanks,
I have seen similar error with:
dynamic views (more sensible to ownership than a snapshot view on C:\, which is your case)
resource handle conflict (the script tries to update a resource already taken by another process, which shouldn't be the case here with your script, since it was working outside of Ant Exec task)
error message (like you create a directory which already exists: the error get ignored in a classic script, while it could interrupt the ant task.
While the last cause is a good candidate, try first to simplify your script (leave only the mkdir for instance) in order to check that this line is indeed the issue (nd not "this line in conjunction with others actions taking place just before")