[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#3224: apsfilter doesn't configure on a read-only filesystem

On Tue, 11 Jun 1996, Carlos Carvalho wrote:

> I mount the server directory in /usr/src/debian. It's done via amd.
> The default mounting is read-write, but the server only exports it
> read-only, so if the client attempts to write in sub-directories of
> /usr/src/debian, including it, the write fails. Here's the msg that
> appears:
>                         ++++ INSTALLATION PROGRAM ++++
>                          [ press return to continue ]
> ------------------------------------------------------------------------
> This script automatically sets up a serial or parallel printer
> spool directories in /var/spool/lpd will automatically be created as needed
> ------------------------------------------------------------------------
> chmod: .: Read-only file system
> dpkg: error processing apsfilter (--install)
> followed by some other dpkg msgs. This probably means that the installation
> script is trying to write something in the current directory.

I think I've fixed this - check out apsfilter-4.9.1-8

> On another issue, I found that the script filtersetup has a somewhat
> non-portable construction. The following patch changes it:
> --- filtersetup.orig    Tue Jun  4 18:12:02 1996
> +++ filtersetup Wed Jun  5 16:34:40 1996
> @@ -38,7 +38,7 @@
>  # are we called by SETUP or are we standalone ?
>  # if standalone, then grab APS_BASEDIR from /etc/printcap file
> -if [ ! $APS_BASEDIR ]; then
> +if [ -z "$APS_BASEDIR" ]; then
>         APS_BASEDIR=`grep APS_BASEDIR /etc/printcap | cut -d ':' -f 2`
>         export APS_BASEDIR
>  fi
> The problem is that if APS_BASEDIR is not defined, we get the
> construction if [ ! ] do_something. This is compatible with the POSIX
> specification of test(1), and works with bash, but fails with true
> bourne shell. Notice that the portable construction is already used in
> many places in apsfilter itself.

This is fixed in -8.

> Finally, I think the index variable in the for loop in line 61 should
> not be path. It's better to use another name, since some shells may
> map PATH to path.

I'll look at this later. Is it causing a problem?

-- Run.exe
runexe@ntplx.net http://www.ntplx.net/~runexe/ Finger me for PGP key
Nine megs for the secretaries fair,    | One disk to rule them all,
Seven megs for the hackers scarce,     | One disk to bind them,
Five megs for the grads in smoky lairs,| One disk to hold the files
Three megs for system source;          | And in the darkness grind 'em.

Reply to: