Re: [mu TECH] NEW: Runtime sound driver configuration (2)

From: Alfie Costa ([email protected])
Date: Mon Apr 24 2000 - 08:11:13 CEST


On 23 Apr 00, at 10:28, Michele Andreoli <[email protected]> wrote:

(AC:)
> > One fix would be to rename this new
> > '/bin/echo' to '/bin/echobin', and call it with 'echobin'.
>
(MA:)
> I, simply, had not accepted the "/etc/profile" patch by Miguel. soundcfg
> is smart enough: it use ECHO=/bin/echo, so no problems.

That is better, (and more 'mu'), than a rename!

Here's another sound config difficulty...

There seems to be a subtle bug in the new sound setup routine, in which 16-bit
sound stubbornly remains set on. What happens is the user eventually gets to a
setup prompt like:

  Enter SB_DMA16 [5]>

...and if one hits 'Enter' it stays 5, and if they input a blank, it stays 5
too.

The bug is not, (depending how we look at it), in the new 'soundcfg', but is
related to how it works, so the trail begins there:

    "Usage: soundcfg [-r] SB_PORT SB_IRQ SB_DMA [SB_DMA16]"

M. Angel has thoughtfully left the SB_DMA16 optional. Some users don't need
16-bit sound; I use an old SB Pro, which is only 8-bit.

That leads to what program calls 'soundcfg'. In 'sound.fun' the 'soundcfg'
script is called with:

    "soundcfg $SB_PORT $SB_IRQ $SB_DMA $SB_DMA16"

For 8-bit sound cards this is no problem, as long as $SB_DMA16 is a null.

What sets the $SB_DMA16 variable is query earlier in the same 'sound.fun':

    prompt SB_DMA16 "$SB_DMA16"

...and after a bit of looking around, it seems that 'prompt()' is defined in
'/bin/setup'. Here's the code:

------
  #
  # usage : prompt var default message
  #
  prompt()
  {

  var=$1
  default=$2
  shift 2

  message="$*"

  if [ ! -z "${message}" ]
  then
      message="${message} "
  else
      message="Enter ${var} "
  fi

  echo -n "${message}[$default]> "
  read answer

  if [ "${answer}" ]
  then
      eval export ${var}=\"${answer}\"
  else
      eval export ${var}=\"${default}\"
  fi
  }
------

The tricky part in 'prompt()' appears to be these two lines...

   read answer
   if [ "${answer}" ]

Now despite the "${}" protection of '$answer' this code doesn't protect
spaces. At least not in the tests I've tried. Here's a few tests copied from
the 'ash' prompt...

 /# read x
                        # I typed a space here
 /# echo Z"$x"Z
 ZZ # it's not there.
 /# x=" "
 /# echo Z"$x"Z
 Z Z # but it's possible to store a space.

I also tried feeding 'read' a quoted space (" "), but then 'read' kept the
quotes too. Not sure what the right fix is... maybe a prompt asking the user
if they have a 16-bit or 8-bit sound card, and then, depending on what they
answered, another asking which interrupts to use?

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:14 CET