Marcel Kilgus wrote:
Arnould Nazarian wrote:
If ex filter_bas,input_file1,input_file2,output_file does not work, but c1=fop_in(input_file1) c2=fop_in(input_file2) ex filter_bas,#c1,#c2,output_file close#c1:close#c2
does work,
then I have the tendency to think that (please remark my precautions) there is a bug, not a feature.
I'd say it's a "feature"...
You want it to work like mv and cp under *nix which if there are are more than 2 file names insist that the last is a directory and move/copy all the previous named files there; which does, in a roundabout way, make sense - however...
How should the EX know in case of a file name whether it's meant for input or for output?
Filters are designed to take one input file (stdin), process it and send the results to one output file (stdout) (ie in a pipeline) with errors going to another file (stderr). If you follow standard *nix (and C), it makes sense in:
ex filter_bas, stdin, stdout, stderr
(stdin = file descriptor 0 [input file], stdout = f.des 1 [output file], stderr = f.des 2 [output file] - however that doesn't preclude a program [re]opening stdin for output, stdin for input and/or stderr for input; just like you did changing stdout to be input as opposed to output with your ex_filter_bas, #c1, #c2, output_file example).
The easy way round would be to write cat_bas which takes its argument list as a list of files and concatenates their contents together on "stdout" and then use it at the begining of a pipeline:
ex cat_bas;<input file 1>,<input file 2>,... TO filter_bas...
Or are you after a kind of merge style:
ex merge_bas, file 1, file 2, ..., file n, merged_file
In which case it's probably easier to stick with the #Ci (i=1..n) method.
[I'd just like to say that all this ex is guess work, based on reading the manual, as I can't check it as my QL is broken and it needs fixing/replacing when I get a chance to sort it out.]
