I just tried running David’s script, and a waterfall of numbers flew by the terminal window. Too many – I couldn’t scroll up to the beginning to see if the script was doing what I thought it was. So how to direct output to a file? A quick Google search brought me to this site, and below is the useful part:
< Standard output >
Many Linux commands print their output to screen. For example, ls does this when it lists the contents of a directory: you see the output, the directory listing, on your screen.cat does the same: it concatenates a file and sends the results to your screen, and thus you can see the file’s contents. But the screen isn’t the only place where the commands can print their output because you can redirect the output of several commands to files, devices, and even to the input of other commands.
The CLI programs that display their results do so usually by sending the results to standard output, or stdout for short. By default, standard output directs its contents to the screen, as you’ve seen with the ls and cat commands. But if you want to direct the output to somewhere else, you can use the > character. For example, to redirect the output to a file, you can use the > character like this:
$ ls > dir_listing.txt
The above redirects the output of the ls command to a file called dir_listing.txt. Because the output is redirected to a file, you don’t see any results of ls on your screen.
Each time you repeat the above command, the file dir_listing.txt is overwritten with the results of the ls command. If you want to append the new results to the file instead of rewriting it, you can use >> instead:
$ ls >> dir_listing.txt
Each time you repeat the above command, the new output of ls is added at the end of the dir_listing.txt file instead of overwriting the file.
The following adds the contents of File1 at the end of File2:
$ cat File1 >> File2
Like I told you before, files aren’t the only places where you can redirect the standard output. You can redirect it to devices, too:
$ cat sound.wav > /dev/audio
As you saw, in the above example the cat command concatenates a file named sound.wav and the results are sent to a device called /dev/audio. What’s the fun here, then?/dev/audio is the audio device, and when you send there the contents of a sound file, that file is played. So if your sound is properly configured, the above command plays the file sound.wav!
Once I did that, I was able to save the file, and I could see that it was, indeed, doing what it was supposed to be doing (of course it was – it was only a matter of me figuring out how to look at it!).
Here’s the top part of the output (before it turns into a waterfall of numbers):
Bytes: 396 RecordType: 7200 fragmentNumber: 0
Bytes: 4613 RecordType: 7001 fragmentNumber: 0
Bytes: 4837 RecordType: 7000 fragmentNumber: 0
Bytes: 13109 RecordType: 7004 fragmentNumber: 0
Bytes: 21905 RecordType: 7006 fragmentNumber: 0
Bytes: 33072 RecordType: 7027 fragmentNumber: 0
%% DATA RECORD FRAME (11167) bytes
ProtocalVersion: 5
Offset: 60
Sync Pattern: 65535
Size: 11167
Optional Data Offset: 0
Optional Data Identifier: 0
Year: 2009
Day: 353
Second: 55.214169
Hour: 17
Minute: 53
Record Type Identifier: 7027
Device Identifier: 7125
System Enumerator: 0
Flags: 32769
Total Records In Fragmented Data Record Set: 0
Fragment Number: 0
DATA SECTION: 11099 (bytes)
Checksum: 788564
--- Data Section --
(Detection Properties Record)
Sonar Id: 0
Ping Number: 0
Multi-Ping Sequence: 0
Points(?): 500
Size(?): 22
Sample Rate: 34482.757812
Transducer Angle: 0.000000
It’s sonar data! It really is! Okay, mostly header info, but still… It’s probably a bit silly to be this excited about simply running someone else’s program. But I had to figure out at least 4 or 5 things just to get to that point, so it’s not a wasted evening, right? :-)
