From: Alfie Costa (agcosta@gis.net)
Date: Mon Apr 24 2000 - 08:11:13 CEST
On 23 Apr 00, at 10:28, Michele Andreoli <mulinux@sunsite.auc.dk> 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: mulinux-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: mulinux-help@sunsite.auc.dk
This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:14 CET