Werner Lemberg wrote, quoting Larry Jones: >> I have one last problem -- contrib/pdfmark/pdfroff.sh makes >> extensive use of the "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. > > Keith, does your latest patch fixes this?
Unfortunately not. See my recent correspondence with Larry; we have agreed between ourselves, that a solution based on the 4th option I identified may be acceptable, unless anyone objected. Ultimately, I may replace `pdfroff.sh' with a C/C++ reimplementation, but the shell function seems like a reasonable short term compromise. The following, which forms part of the correspondence cited above was delivered to Larry, but was undeliverable to addresses at gnu.org; hence I reproduce it here, for reference. Larry Jones wrote, quoting me: >> 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. > > To my knowledge, it has *never* been in the Bourne shell, it is the Korn > shell's (ksh) answer to the C shell's "which" command. On SysV, it is > fairly common to have sh be a link to ksh rather than being the real > Bourne shell (that's how David Korn "proved" that ksh was completely > upward compatible with sh -- he replaced sh with ksh on many of AT&T's > systems and no one noticed), which is probably the source of your > confusion. Well, I'm sorry to dispute this, but that has not been my experience. My first exposure to UNIX was with VentureCom's VENIX implementation, back in 1989. That was essentially a SVR2 implementation, and didn't have a Korn shell -- just a basic Bourne shell, which *did* have `type' as a builtin. I've subsequently replaced that system with a SPARC running SunOS 5.5.1 -- this has both Bourne and Korn shells, both of which are unique ELF binaries, (/bin/sh is 89512 bytes, /bin/ksh is 180932 bytes), and *both* have `type' as a builtin, as they *should* have, because, according to the Waite Group's "UNIX System V Bible", it became standard in System V Bourne shell, as of SVR2. No, any confusion on my part is most likely due to a complete absence of experience of BSD systems, which I understand do lack some features taken for granted in System V :-( > The current more-or-less definitive specification of the shell command > language is that specified by the Single UNIX Specification/POSIX: Thanks for the links [snipped], Larry. I'll take a look, when I have time. >> 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. > > I agree with your analysis. For what it's worth, CVS (which is also GNU > software and widely portable) has the same problem in its test suite > (although not in the core product) and uses a shell function to solve > it. In fact, the test suite makes extensive use of shell functions. So > I suggest going with 4: it's inifinitely better than using "type" and it > seems to be "portable enough". And thanks again, for this. Unless there are any objections from others, I'll investigate a solution based on option 4. Best regards, Keith. _______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
