Copy multiple files into one (append, merge) in single invocation without shell redirection?

Question

I'm looking for some sort of a command that I can use, to copy/append multiple files into one; but without shell redirection (I'd like to try it in call_usermodehelper, see similar issue in call_usermodehelper / call_usermodehelperpipe usage - Stack Overflow). I know I could otherwise use:

cat file1 file2 > file.merge

... but that requires shell redirection.

My findings so far:

• Cannot use cat, as it's default stdout output cannot be redefined (through, say, command line argument) - and other than that, it's shell redirection
• Cannot use dd in single invocation, as it can only accept one (and only one) if= input file argument
• Cannot use cp, as it will treat multiple files individually, and cannot copy them all "merged" into a single location

So - is there any standard tool, that would allow me to do something like (pseudocode):

copytool -i file1 -i file2 -o file.merge

... such that the output file.merge represents file2 appended to file1 contents?

Solution

You can do:

sed -n wfile.merge file1 file2

Or:

awk '{print > "file.merge"}' file1 file2

Or:

sh -c 'cat file1 file2 > file.merge'

(note that depending on the implementation, the first two may not work properly with binary files).

Comments

[Ignacio Vazquez-Abrams]

Why not invoke a shell for the redirection?

[Hauke Laging]

Must it be a single command or would a sequence of commands be OK, too? Would a pipeline be OK?

[sdaau]

Thanks for the comment @IgnacioVazquez-Abrams - when I try to call the shell version from call_usermodehelper (from a timer loop in a kernel function), it seems to "skip" some calls; so for debugging purposes I wanted to try an alternative... as I'm not sure if "instantiating" a shell (and redirections) may represent too much overhead in that context, and an alternative is needed. Cheers!

[sdaau]

Thanks for the comment, @HaukeLaging - I just wrote in the previous comment that I suspect the "shell instantiation" to be too slow for the kernel call context I'm trying it from - and I tried two dds, and those seem to be "skipped" from my timer function call as well. Which is why I'm looking for an alternative... Cheers!

[michas]

+1 for the sh part

[sdaau]

Many thanks, @StephaneChazelas - that is the sort of syntax that I needed (unfortunately, it didn't help with my kernel calls, as they are still being skipped - but at least now I know those "skips" are not due to shell redirections). Many thanks again - cheers!

[jarnosz]

+1 the awk program solved a viewer update for groff postscript output broken with redirection.