Ian Jackson wrote: > > We only have room for one `extra' scripting language, besides the > usual sh, awk, sed, &c, on the base disks. > > Perl is widely known. It can solve most problems. There are problems > for which it is difficult to get it to work, but these don't often > occur at installation time. > > sh is not suitable for many of the things Perl gets used for - > consider update-inetd, update-info &c.
Actually, a /bin/sh script to add inetd.conf entries, and another to remove entries keyed off the service field, was unmentionably simple to code, and has proved quite reliable in (lots of) practice. > For this reason we decided that Perl would be on our base disks, and > that packages could use it (well, the subset that's on the base disks) > in their preinst/postrm. Packages which want something else must > Depend on it and may only use it in their postinst/prerm. There's clearly a place for a stronger scripting language, despite the argument posed above. It's just very sad that it should be perl. perl really fits into many people's stereotypes of "unix as inherently cryptic monster", very neatly. > There is no point having a religious war over this; this decision was > taken a long time ago and can't be changed now, even if we wanted to. This is rhetoric. It could be changed and you know it. What I mean to say is, I really dislike "can't" when what's meant is "won't". I daresay that a linux distribution (or the Hurd, or *BSD, or...) that doesn't fall into the perl trap, should have a brighter future. > Ian.
