On Friday 13 November 2009 16:35, McKown, John wrote:
>Thanks for the reply. I'm very new to all this, so I appreciate the thoughts
> of those who are steeped in the "whys" of UNIX. Actually, my original
> solution was to use an environment variable to list the files to be read
> (didn't think of the seeking around in the set of files - yuck!). But I
> guess something like:
>
>command --input1=file1:file2:file3 --input2=otherfile:andmore regular.way
>
>would be more UNIXy to implement in my code. This would assume that for some
> reason, I must know of multiple files which contain compatable information
> and keep them separate from other sets of files with differently compatable
> information. That, in itself, may not be very UNIXy.
That's correct: having the kernel know anything about the contents of files is
A Bad Thing (tm) in the UNIX world. That's what user-space processes are
for. Files are just containers for bytes.
The exception is directory entries, which one could argue are known only to
the filesystem layer of the kernel so it's OK, but their contents are used by
the kernel. That's why I'm thinking of a new file type of "meta-file".
I thought the original poster rejected the idea of named pipes because of
concern about the I/O overhead? Named pipes are the UNIX-style solution to
this problem, but can they match the performance of a concatenated dataset?
Is the I/O overhead of pipes significant in this context?
- MacK.
-----
Edmund R. MacKenty
Software Architect
Rocket Software
275 Grove Street · Newton, MA 02466-2272 · USA
Tel: +1.617.614.4321
Email: m...@rs.com
Web: www.rocketsoftware.com
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
