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
Related
Recently I tried to list all of the images located in a directory I had (several hundred) and put them into a file. I used a very simple command
ls > "image_names.txt"
I was bored and decided to look inside the file and realized that image_names.txt was located in the file. Then I realized, the order of operations performed was not what I thought. I read the command as left to right, in two separate steps:
ls (First list all the file names)
> "image_names.txt" (Then create this file and pipe it here)
Why is it creating the file first then listing all of the files in the directory, despite the ls command coming first?
When you use output redirection, the shell needs a place to put your output( suppose it was very long, then it could all be lost on terminate, or exhaust all working memory), so the first step is to open the output file for streaming output from the executed command's stdout.
This is especially important to know in this kind of command
cat a.txt | grep "foo" > a.txt
since a is opened first and not in append mode it will be truncated, meaning there is no input for cat. So the behaviour you expect that the lines will be filtered from a.txt and replace a.txt will not actually happen. Instead you will just lose the contents of a.txt.
Because redirection > "image_names.txt" was performed before ls command.
My question is about file handling in bash.
I want to write a string to text file in Bash script.
I have already tried
echo string>>filename.txt
your code is correct.you can write to a file using that.But you have to check the file access permission of the file you want to write the data in to.
Check following for more details.
Create text file and fill it using bash
Open and write data to text file using bash/shell scripting
That is a valid way of doing it. I would however consider this:
echo "string" >> file.txt
The quotes make it possible to handle more than one word (in the case of echo, that works anyway, but it's good practice to always use it). You should also distinguish between > and >>
> truncates the file (erases it) and replaces its contents with your string
>> on the other hand appends your string to the bottom of your file
I'm writing commands that do something like ./script > output.txt so that I can use the files in later scripts like ./script2 output.txt otherFile.txt > output2.txt. I remove them all at the end of the script, but when I'm testing certain things or debugging it's tricky to search through all my sub directories and files which have been created in the script.
Is the best option just to create a hidden file?
As always, there are numerous ways to do so. If you want to avoid files altogether, you can save the output (STDOUT) of a command in a variable and pass it to the next command as a file using the <() operator:
output=$(cat /usr/include/stdio.h)
cat <(echo "$output")
Alternatively, you can do so in a single command line:
cat <(cat /usr/include/stdio.h)
This assumes that the next command strictly requires a file for input.
I tend to avoid temporary files whenever possible to eliminate the need for a cleanup step that gets executed in all cases unless large amounts of data have to be processed.
The following command line executes properly:
MagBoltz32 < input.txt > out.txt
The executable requires the input in brackets as above and outputs the text file. The following "batch.BAT" file (now including the escape characters) does NOT execute but simply hangs as if expecting more input.
MagBoltz32 ^< input.txt ^> out.txt
Executing batch.BAT simply results in a blinking cursor. Ultimately this command line will go into FOR loop which loops over several input/output files. I do have access to the source code.
That's not "input in brackets". The programm doesn't use any parameters (at least not in the shown syntax). It gets it's input from STDIN and writes to STDOUT.
<input.txt redirects the content of input.txt to STDIN, so the program is able to use it, like it were entered per keyboard.
>output.txt redirects STDOUT to the file output.txt instead of writing it to the screen.
Escaping characters is only needed, if you want the special char to be shown on the screen instead of "executing" it (simply spoken), so in your case, escaping the redirection characters makes no sense, but disables the redirection.
In some OS's you need to escape the pipes <, > and | so the syntax could be completely valid. This is particularly true for batch files (http://www.robvanderwoude.com/redirection.php) ... Have you checked to make sure all the files are in the same path that is executing the batch file? If you run the batch from C:\foo even though bath.BAT is in c:\bar, the input.txt will be expected to be in C:\foo.
Problem 1:
I'm using a self-made command, that for reasons, cannot be changed. The command requires a filename that it will read from like so: read-cmd "testtext.txt" I know it's possible to use files as a stream of input for some commands using input redirection, e.g. some-cmd < "text.txt", but I'm wondering if the opposite is true, whether I can use a line of text and make bash believe it's a file, so that I'd be able to do read-cmd "contents of what should be in a text file"
the only thing I've been able to do is
Example 1:
echo "contents of what should be in a text file" > tmptextfile
read-cmd "tmptextfile"
rm tmptextfile
I would however, really rather not do this, and rather just stream that line in as if it were a file. Is there any possible way to do this, or would it rely entirely on how read-cmd works?
Problem 2:
A very similar issue, however, instead of the file being an input to a command, it is the input to an option of a command. So, read-cmd2 -d "testtext.txt" ...
Example 2:
echo "contents of what should be in options text file" > tmpoptfile
read-cmd2 -d tmpoptfile ...
rm tmpoptfile
whether I can use a line of text and make bash believe it's a file,
Yes you can use process substitution for this:
read-cmd <(echo "contents of what should be in a text file")
Process substitution is a form of redirection where the input or output of a process (some sequence of commands) appear as a temporary file.