"Jeff Hostetler via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > + ls | test-tool hexdump | grep "63 5f c3 a9" A few comments: * Not folding output lines at arbitrary place like "od", "hd", etc. does, is a good design decision made by "hexdump" here. Depending on where in the pathname the 4-byte sequence appears, tools from other people may split the sequence across output lines, making grep ineffective. But our hexdump would work fine here. * For the narrow purpose of the tests in this script, output that is a single long line produced by hexdump might be sufficient, but I wonder if it makes the tool more useful if we at least placed the hexified output for each line on separate output lines. * Purist in us may find it a bit disturbing that exit status from test-tool is hidden by the pipe. I do not care too deeply about it, as it is very unlikely that we care about segfault after hexdump successfully shows the substring the downstream grep is looking for, but it does make us feel dirty. A devil's advocate suggestion is to go in the completely opposite side of the spectrum. Perhaps if we are willing to limit the tool's utility to the tests done in this script file, it might be a good idea to combine the latter two elements in the pipeline, i.e. ls | test-tool hexgrep 63 5f c3 a9 that exits with 0 when the output from "ls" has the 4-byte sequence, exits with 1 when it does not, and exits with 139 when it segfauls ;-)
