I came across the below shell command:
$prog.sh < file_name.json
I know it reads from a file, but how and where does prog.sh load the file?
Every program has three open file handles at startup, one of which is standard input. Normally, the file handles are inherited from the parent process. The < operator tells the shell that, instead of passing its standard input to prog.sh, to open file_name.json instead and give that file handle to prog.sh as its standard input.
$prog.sh < file_name.json
As you rightly guess. The < is meant for redirecting the input from a file so that your script will read from the file which will be the (temporary) stdin(fd0).
it read from a file, but how and where prog.sh will load the file
It depends on how you plan to go about it. Any command in the script that expects an input from the stdin will now read from the file. The new line character in the text file (usually) stands for the ↵ in the stdin.
Related
I'm working on a script, that requires you press control + d when you complete your entries. I'd like to send this command so I can just script my work rather than having to redo my work.
You're probably talking about the "end of transmission" delimiter which is used to indicate the end of user input. If that's the case then you can always pipe data into your script. That is, instead of this:
$ test_script.sh
My input!
^D
You'd write that data to a file:
$ cat > input
My input!
^D
Then pipe that into the script:
$ test_script.sh < input
No ^D is required because once that file is fully read the script is signalled accordingly. The < shell operator switches STDIN to read from a file instead of the terminal. Likewise, > can be used to capture the output of a program and save it to a file, as done in the second step here, though you can use any tool you'd like to create or edit that input file.
This works with pretty much any scripting language, from Python, Perl, Ruby to Node.js as well as bash and other shells.
My understanding is that the redirection operator, <, should allow me to take text from a file and give it as input to another file as if I had written out the contents of that file. Here is what I am trying to do:
python code.py < input.txt
I expect this to act as though I had typed the contents of input.txt after python code.py, but instead it acts as if I passed no input.
If I use cat, I get the contents of the file:
> cat input.txt
['2015-1-1','2015-5-1','2015-9-1','2015-10-1','2015-12-1','2016-1-1','2016-2-1','2016-4-1','2016-5-1'] [65,50,30,45,55,39,45,30,20]
And if I just copy and paste the contents of the file, I get the correct behavior.
I know this must be a really simple misunderstanding on my part, but I can't figure it out.
It's called Redirection, not piping, but you are correct that the < operator will push the file to the command. You can see this in action by using Sort instead of echo.
sort < input.txt
This will display the text file as a list, sorted alphabetically. Echo does not work with text files, so sending a text file to Echo simply runs "Echo".
If you just want to send a file to the command window, you can use Type instead, and not use the redirector.
type input.txt
When I run an a.exe file as below it is running fine:
C:\forc>a.exe 'iss mac'
6
(Output is 6)
How to provide this input from a text file?
I tried the below but no luck:
C:\forc>a.exe < input.txt
C:\forc>a.exe 'input.txt'
Kindly help.
the only time that you will be able to pass file contents into a program is when the program accepts a filename in the command line arguments or if the program is designed in a way that lets it read all the contents of the standard input stream. For example, in C#, you would treat Console.In in the same way you would treat a file input stream (read lines, chars, etc)
in conclusion
the program must directly support consuming data from standard input in order to use the < redirection. Standard Input is NOT the same as a command line argument.
Whether you can send input to a.exe depends entirely on a.exe. You will need to read the documentation for a.exe, or ask its author, to determine whether what you want to do is possible.
From Alexei Levenkov answer :
Using command redirection operators
program.exe < input.txt > output.txt
I would like to know if it's possible to get the output redirection file name as a parameter in bash?
For example :
./myscript.sh parameter1 > outputfile
Is there a way to get "outputfile" as a parameter like $2? In my script I have to do few operations in outputfile but I don't know which file I have to update... The second problem is, this script is already running and used by several tasks so I cannot change the user input...
Best regards
Redirections are not parameters to the program. When a program's output is redirected, the shell opens the file and connects file descriptor 2 to it before running the program. The program then simply writes to fd 2 (aka stdout) and it goes to the file.
On Linux and similar systems you can use /dev/stdout, which is a symbolic link to the process's stdout file.
I am executing a script and redirecting the output to text file using command sample.sh -base BUG2 1> output.txt 2>&1
now in the script i want to read the contents of the text file to grep some words.so how can we read that text file while the script is running.
If I get it well, you want to execute a script, and redirect its standard output into a file and on standard output: tee is what you are looking for.
This command redirect its standard input into a file and on its standard output (http://ss64.com/bash/tee.html)
sample.sh -base BUG2 | tee 'file.txt' | more_script
I'm not sure I understand your question correctly, but from what I can guess and assume, it appears that you're trying to read from, and write to the same file.
You will be able to do so, but you won't be able to rewind, as Bash can not seek.
Read more on redirections.
If you're trying to do something like this: cat file | sed s/foo/bar/ > file, i.e. Reading from a file and writing to it in the same pipeline.
That woul'd be impossible.
You cannot read from a file and write to it in the same pipeline. Depending on what your pipeline does, the file may be clobbered (to 0 bytes, or possibly to a number of bytes equal to the size of your operating system's pipeline buffer), or it may grow until it fills the available disk space, or reaches your operating system's file size limitation, or your quota, etc.
( Quoted from Bash Pitfalls 13 )