I think Don's script has found a bug in your, what looks like a, perl script; wherever that came from!?
I could be wrong but it looks as though your script cannot differentiate between 0, (zero) as a number and 0, (zero) as a file...
-g 0
Did you test your _perl_ script with a file named "0"?
Just a thought, as Don's script looks as though it generates a file name "0".
Hi zajtat,
Yes, the first invocation of combining.executable:
creates a file named 0 and the second invocation of combining.executable:
uses file 0 and creates file 1. Subsequent passes through the loop alternate between creating file 0 and using file 1 on odd numbered invocations (after invocation 1) and creating file 1 and using file 0 on even numbered invocations.
And, on OS X, the script I suggested works with both bash (version: GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin15)) and with ksh producing the output you said you wanted with the three input files you provided as samples in post #1 in this thread (except the order of the 1st two lines in the output was switched) with combining.executable being the script:
which works fine as long as the input files are text files. Note that with the number of files you are combining, the above script might or might not work. The awk utility is only required to work on text files and some of the files this script will be processing will not be text files (due to excessive line lengths).
If your perl script won't accept 0 as a filename, that is your problem. The script I provided (after changing the 1st line to use your shell) meets all of your specifications.
If you would like to give us a clear specification of the allowed filenames for the -g option to your perl script, I might be able to help you make the script I suggested use different temporary filenames.
Also note that bakunin has a typo in his bash invocation second part:-
#! /bin/bash
......shloud be......
#!/bin/bash
......without the whitespace between "!" and "/".
Sorry to correct you, but this is NOT a typo and it was indeed intended that way. Here is a bit of UNIX history:
The UNIX kernel has to have some clue about what constitutes an executable file. OK, there is the x-bit in the filemode, but still, the kernel has to know what to do. For binary files there is the so-called "magic number", which is the first 4 bytes of an executable. Look at any first 4 bytes of binary, compiled files in your system and you will see that they are the same.These 4 bytes tell the kernel to use some member of the exec*() family of system calls to actually execute it.
Unfortunately this is not possible with the input files of the many interpreters a system has: all sorts of shells, awk, sed, many editors (ed, ex, ...) which can be scripted, and so on. Historically there was only one shell and the UNIX kernel had a special provision to try invoking the shell with the file as input in case the magic number was not understandable. Today this has been altered to the system default shell and is still in place: you can see it at work when you write a script without any shebang line. In this case the startup process is like: the kernel finds no valid magic number, then loads the system default shell (which is a normal executable binary) via normal exec*(), then feeds it the file in the hope that the shell can make sense of it. If it is indeed a shell script, it does. If not, you will see some error message, which is coming from the shell, not the kernel itself.
But as UNIX evolved and many different shells (and other interpreters of script-like text) were available the developers of UNIX searched for ways to name the specific shell/interpreter for scripts. The UNIX kernel was extended for a new magic number and this four-byte code was:
If the kernel finds this magic number it reads the rest of the first line, loads the specified interpreter and - upon succeeding in that - feeds it the file as input. Because the '#' is a comment to the shell it doesn't alter any script at all, the shell will just ignore it like any other comment.
This is the reason why you have to have the shebang in the very first line and why it is not allowed to be indented and why you have to use the absolute path of the shells executable: #! /bin/bash is a legal shebang, #! ../../bin/bash is not.
So, basically, the correct shebang line is:
Unfortunately most people were not able to reliably put a single space where it belongs and many wrote
Which was still a normal comment and the kernel would - failing to recognize the magic number - still load the default shell, but maybe not the specified one. Which is why the kernel was extended again to also recognize a special 3-byte magic number, which was the shebang without the space.
This is the situation we have now. Basically it doesn't matter any more if you write the space or not, but, being as old as i am, you have to have something that sets you apart from the youngsters (save for having to get up at three in the morning to pee). Therefore i always write the "originally correct" shebang, and not these newly-invented hacks which are only going back to the seventies.
Hi bakunin,
Sorry to disagree with you here, but back in the early UNIX days on the PDP-11, the magic number determining the type of executable was 2 bytes (16-bits) not 4 bytes. And, when #! was added to the magic numbers recognized by the kernel, a leading space was not allowed. Since then, some kernels allow one or more leading spaces, some kernels allow a single option (e.g., #!/bin/sh -xv), and some kernels may even invoke a shell to evaluate the entire first line starting from the 3rd character as a shell command with the rest of the file as input (although I am not aware of any of these systems that are still produced today).
I believe that the PWB UNIX Systems I used when I was learning the OS treated:
as a request to run the sh utility in the bin directory in the <space> directory, but I don't remember if it interpreted it as / /bin/sh or as ./ /bin/sh.
I was going through the post again to look over things and have double-checked that the perl script works fine with files that have numbers as names. There are no bugs in perl script and there has never been such a problem, that's why I've answered a question about the name of the output file that it does not matter. I did try to provide clear information and answer all the questions to the best of my abilities and I apologise that it was not understandable. Thank you all of your time and help once more!
I was going through the post again to look over things and have double-checked that the perl script works fine with files that have numbers as names. There are no bugs in perl script and there has never been such a problem, that's why I've answered a question about the name of the output file that it does not matter. I did try to provide clear information and answer all the questions to the best of my abilities and I apologise that it was not understandable. Thank you all of your time and help once more!
The trace output you showed us in post #11 in this thread indicated that the command:
succeeded, that the next command:
failed producing the diagnostic:
and, then it appears that the command:
succeeds (although we didn't look at enough of the trace output to be sure of that).
You say that your script works with an input file named 0, but you have shown us diagnostic output from the script (as copied above) that clearly shows that it does not. Should we believe what you showed us in post #11 or should we believe what you said in post #20? They are in direct conflict with each other.
Hi,
I have some output from 'ls' command and I want to loop over the output in a bash script. What would be a good way to go about it?
For example, if the output of the ls command gives me 'prefix1 prefix2 prefix3', how can I set a loop that will iterate over these?
many thanks! (5 Replies)
Hi all,
I am trying to loop through the string contents of an array, to add it during the saving of the output files. I am trying this code to print each column and save it to unique file name, but it doesn't work. Thanks for any help.
fnam=(japan usa uk)
alldata.dat contained sample data... (1 Reply)
I have been trying this program for a long time. I am trying to read a file named "odon" line by line; read the first line, send it to do a command saved in a file "perm", once the first line has finished going through the content of the file perm, the result is saved with the number of the line.... (17 Replies)
Legends,
I want to remain in the script until user passes the correct name.
I had tried the below code; but it didn't work out.
Please help
echo "\nPlease enter the source system: \c"
while read SYSTEM_NAME
do
if ];
then
echo "\nMaking $SYSTEM_NAME as source system for particular... (5 Replies)
Hi friends,
I'm newbie to SVM.
Just wanna try installed it on one of our server (to do mirroring for disk0 and disk1) but i think im lost until now. :(
the steps i've taken is as below:-
1.prtvtoc /dev/rdsk/c1t0d0s2 | fmthard -s - /dev/rdsk/c1t1d0s2
2.metadb -a -c 3 -f c1t0d0s7... (3 Replies)
Hi,
I have two files , one file with data file with attributes that need to be sent to another file to generate a predefined format.
Example:
File.txt
AP|{SSHA}VEEg42CNCghUnGhCVg==
APVG3|{SSHA}XK|"password"
AP3|{SSHA}XK|"This is test"
....
etc
---------
test.sh has... (1 Reply)
Hi there
could anybody point me in the right direction when it comes to looping through the output of a system command in perl (i.e. df -k) doing a test against each line to see if it matches?
for example if i have a df -k output like this and I wanted to grab the lines that matched "sda" or... (3 Replies)
Hi,
I am having an Input file .which is having a list of names.
comapring with our database , needs to write the out put in file called output.txt , format should be name--> country--->phone number
could you please help me..
thanks in advance (7 Replies)
This site has been very helpful thus far.. I thank you all in advance for sharing the knowledge. Let me get to it.
I am trying to write a very small script to take away from the boredom of doing the same thing over and over.
Everynow and again I have to get the hex value of a file using a... (2 Replies)