Jean-Francois Moine writes:
| On Thu, 03 Jul 2003 18:52:54 UTC, John Chambers <[EMAIL PROTECTED]>
| wrote:
| [snip]
| >I've discussed with Jef the idea of merging the jcabc2ps
| >extensions into abcm2ps. I'd like to use some of his
| >extensions, too. Maybe we can work on this character-set
| >issue a bit more, and then look into starting the merger.
|
| I did some merge in abcm2ps-3.6.2, but I will not change the
| command-line options ('+' instead of '-') nor the voice name
| separator for many lines ('\\' instead of '\n').
|
| May you check the remaining things to do?
I wonder whether we should keep discussing this on
abcusers, or do it in private? A public discussion does
have the advantage of keeping others up to date on what
we've done, and it invites their comments. I can think of
several cases where we might want to bring in the question
of what's the best way to do something, with the idea of
putting it into the standard.
One command-line change that I made, which others might
find useful: I changed the input/output so that jcabc2ps
acts like a conventional unix "filter". If there are no
input files, it reads from stdin. If there are no output
options, rather than writing to Out.ps, it writes to
stdout. This way, I can use preprocessors (like abcpp) and
postprocessors (various perl programs I have that munge
postscript), without the mess of creating intermediate
files and then trying to make sure that they're cleaned up.
I found that this really simplified the cleanup job for my
tune finder's conversions. If you don't need to produce
intermediate files, you don't have much cleanup.
Implementing this turned out to be fairly easy. The first
stage was to to through and changed every "printf(" to
"fprintf(stderr,". I verified that the result never wrote
to stdout at all. This is important, because you don't want
to get warning messages mixed with the ps. And to fit in
with other unix software, messages and warnings really
should go to stderr.
The next stage was to find the references to "Out.ps", and
change them to deal with stdout instead. This wasn't quite
as trivial, but not terribly difficult. It only took a few
tries before "jcabc2ps foo.abc >foo.ps" produced a foo.ps
that worked ok.
Changing the input to use stdin when there were no input
files was also pretty easy. It mostly consisted of finding
the error messages and changing them to accept a null input
file name as a synonym for stdin.
I did introduce two global flags, use_stdin and use_stdout,
that kept track of what was being done. This wasn't really
necessary, but it made the code a bit simpler and more
readable. A quick check shows that the only C files that
changed were jcabc2ps.c and subs.c, which is probably no
surprise. I could send you the relevant sections, but you
can likely find them just as fast yourself.
I have the impression that, at least on unixoid systems
(which now includes Macs), lots of others have uses for
pre- and post-processors, so many users would find this
useful.
The -o and -O options could be left alone, though I do find
it handy to make -o the default. It's really nice if
the commands
abc2ps foo.abc >foo.ps
abc2ps <foo.abc >foo.ps
do exactly what you expect them to do. This saves me a lot
of "Oops!" reactions and repeating the command with -o
included.
I suppose you might want another option to suppress ps
output if you don't like the -/+ convention that I adopted.
Or you could use the backwards approach that a lot of
people seem to like, with -o meaning produce ps and +o
meaning don't produce ps output. This strikes me as a bit
perverse, but it's common enough these days.
Of course, true unix geeks would just use ">/dev/null" to
suppress the output.
Anyway, maybe you should set up an "alpha release" URL for
abcm2ps, and we can create a fast testing loop. I have a
sizable collection of tiny abc test files, most testing
just one feature. I can easily make an abcm2ps test
directory with the same test files, and tell you where I
get failures.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
