Re: [ecasound] ecasound-2.5.2 does not allow commas in input file name

From: Kai Vehmanen <kvehmanen@email-addr-hidden>
Date: Sun Apr 12 2009 - 21:59:26 EEST

Hi,

On Fri, 10 Apr 2009, Sergei Steshenko wrote:

> So, I had to add
>
> s/\,/\\,/g;
>
> to my code for ecasound to accept the file name. I.e. ecasound behaves
> differently from bash for which String::ShellQuote::shell_quote_best_effort
> is written.

yep, that's because commas are strictly a ecasound specific oddity -- they
have no special meaning for bash. This is indeed confusing when you need
to pass arbitrary params to ecasound from a shell script, as you need to
deal with both two sets of special-purpose characters.

Note that you can also quotes to pass commas. Following all three work
in bash for a file that contains both whitespace and commas:

ecasound -i '"foo, bar.wav"' -o ...
ecasound -i "\"foo, bar.wav\"" -o ...
ecasound -i "foo\, bar.wav" -o ...

... the first two variants should be easier to use in scripts.

In retrospect, comma was perhaps not the best choice for the param
argument separator. On the other hand, at least for me, the alternatives
have their problems as well (although I do admit I really didn't even
consider any alternatives when settling on commas):

  - the best alternative would have been to use whitespace, but
    this has some negative side-effects well:
      - more verbose
      - as many objects support variable number of params, some
        kind of end of params marker would be needed, which is very
        error prone (e.g. having to end each parameter list
        with a "." as used by some console apps)
  - requiring all params to be quoted (in practise, always quoted
    multiple times as shell removes the outer quotes) .. a clean
    design, but not very practical
  - trying to pick another ascii character that appears less often
    than comma in valid params
      - | & ; ( ) < > space tab ; ... are already taken
      - the reserved words.. ! [ ] { } ... are a bit easier from
        shell-semantics point of view, but these appear quite often
        in filenames
      - and even if a better character is found, this doesn't really
        help when one needs to pass arbitrary (perhaps UTF8) params

... again, in retrospect, whitespace would still have been a better
choice. The command-lines would of course look quite different:

ecasound -i somefile.wav -o alsa -ef3:800,1.5,0.9 -kos:1,400,4200,0.2,0
-kos:2,0.1,1.5,0.15,0

... would be instead something like...

ecasound -i somefile.wav . -o alsa . -ef3 800 1.5 0.9 . -kos 1 400 4200
0.2 0 -kos 2 0.1 1.5 0.15 0 .

... doesn't look too bad actually. But oh well, coming out of
retrospect-mode, I think we are stuck with commas...

Still, I'm open to ideas on how to improve the syntax (especially
any good incremental changes).

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Mon Apr 13 00:15:03 2009

This archive was generated by hypermail 2.1.8 : Mon Apr 13 2009 - 00:15:03 EEST