Larry Jones wrote: > ... I have one last problem -- contrib/pdfmark/pdfroff.sh makes extensive > use ofthe "type" command, which is *NOT* a standard shell command. I was > able to work around it by changing the first line from #!/bin/sh to > #!/bin/bash, but it should probably be rewritten portably.
Really? I didn't know that, sorry. I used `type' to check that all of the necessary prerequisite programs are installed, because I understood that it *was* standard in Bourne shell; I've never come across one that didn't have it, but my experience has been exclusively with System V, (since SVR2), and more recently with GNU/Linux. I followed the portability guidelines in the Autoconf documentation, which does not list `type' as a non-portable Bourne shell builtin, (in the `info' for 2.59) :-( I agree that portability is desirable. Clearly, `type' is not supported by the BSD Bourne shell, but what alternative would you suggest? Substituting `/bin/bash' for `/bin/sh' certainly *isn't* an option, since that would be even less portable. Some possibilities, which occur to me, are: 1) Simply assume that all prerequisites are satisfied by programs which are already in the PATH; breaks in an unpredictable fashion when anything is missing, and can't (easily) handle the case where GhostScript might be installed as `gsw32c.exe' rather than `gs'. 2) Allow `configure' to make the choices, and patch the appropriate program paths into `pdfroff' at `make' time; breaks if the runtime host is not congruent, wrt program locations, with the build host. 3) For each test currently implemented using `type', reproduce the program file location strategy used by Autoconf; this is likely to result in the most portable solution, but is rather long winded. 4) Implement `type' as a shell function, based on the Autoconf strategy, within `pdfroff.sh'; this would appear to be the most attractive option, *but* the Autoconf documentation says not to use shell functions. Any other suggestions? Regards, Keith. _______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
