Re: question about sound
On Sat 20 Aug 2022 at 07:46:24 (+0200), tomas@tuxteam.de wrote:
> On Fri, Aug 19, 2022 at 11:55:33PM -0500, David Wright wrote:
> > On Fri 19 Aug 2022 at 08:46:29 (-0400), Greg Wooledge wrote:
> > > On Thu, Aug 18, 2022 at 11:13:11PM -0500, David Wright wrote:
> > > > The attraction of a one-liner is partly because of screens
> > > > being around four times wider than high (characterwise).
> > > > Wouldn't it be nice if bash had Perl's die ….
> > >
> > > Some people put a die() function in their scripts, and then use it.
> > >
> > > die() { printf >&2 '%s\n' "$*"; exit 1; }
> > >
> > > Or variants thereof. There are almost as many variations as there are
> > > shell programmers.
> >
> > But if I have that, and:
> >
> > soxy is a function
> > soxy ()
> > {
> > [ -z "$1" ] && die "Usage: ${FUNCNAME[0]} path-to/sound-file-of-any-type [trim 20 2]
> > runs sox to play the file with any arguments given.
> > The example above reminds you to put the full argument.";
> > local From="$1";
> > shift;
> > sox -q "$From" -t alsa default "$@"
> > }
> >
> > then typing just:
> >
> > $ soxy
> >
> > into an xterm will have the same effect as:
> >
> > $ ^D
> >
> > killing bash and the xterm, whereas what I would want from die is a
> > "double-return", quitting both die and soxy, and leaving me at:
> >
> > $
> >
> > just as Perl's die would do (if soxy was a Perl program).
>
> The problem is... the function is running in your current shell's
> process. This is totally different from the Perl case, where your
> Perl programm gets its own process, so exit is going to do the
> right thing (in both cases, the current process is terminated).
>
> (Actually, Perl is more complicated, since you can catch a die
> with an eval, so it is basically a full-fledged exception machinery).
Yes, I understand that, I was just using Perl to illustrate the
concept: if I run a Perl program from the command line and, deep
within the program, it executes die, I get a message and I'm back
at my command line.
> I see two ways forward: either use return in your shell function;
A macro in emacs made light work of that.
> you'd have to build your exception handling level-by-level, by
> hand.
90% of the functions are single level, built to make CLI use
more efficient. They error check (evidently for likely errors,
rather than, say, closing stderr), and second level functions
are generally trivial, like:
[ -e "$2" ] && msgerr "$2 already exists!" && return 1
… …
msgerr ()
{
printf '%s\n' "$*" 1>&2;
return 0
}
> Or do what everyone does and build your soxy as a command,
> which will be executed in its own shell and not as a function.
I would think that rather OTT, seeing as soxy merely avoids
having to remember the options -q and -t alsa default.
Many of my functions are similar; can you imagine having to
remember all these options just to put a video soundtrack
onto a GoGear mp3 player:
ffmpeg -y -i "$1" -f wav -ar 44100 -ac 2 -vn "$Unique1"
lame -b "${Fixedbitrate:-128}" "$Unique1" "$Unique2"
chmod ug=r,o= "$Unique2"
touch -r "$1" "$Unique1" "$Unique2"
> You can set traps in the shell for exit and return events, so
> you might try to build exception handling on that, but I don't
> know whether it is a good idea. But possibly a nice exercise :)
By that time, I would have rewritten shell code in Python. For
example, I ran a shell script for years to change the X background
according to temperature/battery state, but wheezy's 3.x kernel
introduced a snag: that /sys/class/power_supply/BAT*/current_now
might exist when tested, but not when read by the next line of
code. I just converted shell to Python, and used try:/except:.
Cheers,
David.
Reply to: