Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


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

no habla bash muy bien...



miah mentioned:
| On Thu, Jan 29, 2004 at 06:35:04PM +0000, John Chambers wrote:
| > Why not?  If you can rely on your customers' systems having  perl  or
| > python  (perhaps  because  they  came  with  the CD that you had them
| > install), then there's no reason not to use them.
|
| Serious problems if you're attempting to boot the system and perl is in /usr/bin, and its not mounted yet and your initscripts require perl.  This is why sh/bash are in /bin as well as many of the other commonly used shell tools (like sed,awk, grep, cut).

Indeed. But this isn't just a problem with perl.  I've seen
several systems that made serious use of java, and they did
mention that figuring out how much of java had to be in the
root partition was a real Learning Experience. Perl, python
or any other language that loads code at run time is likely
to present the same problem.

I've also read of problems with distributions that have two
versions  of  sh,  bash, etc; one statically linked and one
dynamically linked.  If anything in the boot sequence tries
to  use  the dynamically linked version of a shell, you get
the same kind of failure.

You can also get the same  sort  of  disaster  in  a  shell
script  by  using  "source"  to  load  something that's not
mounted yet.  This really is the same problem as not having
a dynamic link library (or a java class library) available;
it's just visible in the source code.





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org