> > and both systems contain bash, that interprets the script, why the > > difference on syntax? > > > > Can you attach to bash script you are running and the exact error > messages? It is hard to say (at least for me) without seeing it; bash > to bash portability issues are something I have never heard of. As a > guess there are a variety of options you can change while running in > the interpreter with the "set" command that can also be set in > configuration files or the command line. Also possible is that the > install CD contains a gimped version of bash, but typically then it's > not called bash. It could also be running it with "set -o posix" for > some reason.
The script itself is of not interest -- it is just particulars -- that i can change even right on the target machine, though it is hard to do for many lines and w/o mcedit at least, not to say graphical editor -- w/ the everywhere existing nano! :o) I simply wonder the phenomena. And having not found the answer myself, would ask more experienced users of "Gentoo". > The installation process at its core involves preparing the disks and > then extracting the stage 3 to them. Disk preparation can be > exceedingly complicated and making an automated installer that > supports all possible setups is pretty hard, only fairly recently have > distributions like Debian been able to offer automatic setup of > encrypted LVM volume groups. Some possible configurations (per PV > keys) still aren't supported. It is not always required. So, this part could be done manually still whereas the rest -- automated, like usual installer does. > The other part is creating a kernel. For that there is genkernel, but > it just compiles everything in. I'm not sure that counts as > configuration but it is automatic. Again, nothing keeps us from using several commands to compile customized kernel, starting w/ /usr/bin/make menuconfig > I do think the handbook leaves far too many things out that normal > users would need. I'm trying to compile a list of useful x86/PC > related things to add to the handbook at some point, like useful > default make.conf and portage options. There's also a lot of > configuration files to sort through, documenting files of interest (if > not providing some default configuration for them) is probably a good > idea. Of course! Best practical knowledge should be accumulated in the documentation and included as default presets for the installation or later system administration. You remember, i did rise here question on profile customization? -- So, i thought out that base profiled is too "thick" to be called base or default. I think, only working kernel, package manager and network -- speaking of installed and self booted system -- should be installed and called base/default and from that base all other profiles grow. Also, all those other profiles should not to be as next step to develop and grow the installation, but checklists of packages w/ corresponding checklists of the packages dependencies -- just like "Debian" does for its compiled packages w/ that differences, that choosing process will be followed not downloading and installation only, but compilation also. -- These i call "all about choice", so that user/admin had not to fight w/ the profiles that are totally unnecessary at wide angle of view, but rather add some automation for the lazy -- like client wants KDE suite -- alright, get it -- and so forth. But for the concerned, are those checklists of packages -- when everyone can choose what is desired likewise USE, CFLAGS -- all through checklists, so that the user will not search the web for the well known stuff, but right in the system configuration might see all that is available w/ comments on what and why it does, as well as pros and cons that follow the choices. All this simplifies the process of installation and farther support of systems. Nobody likes to wade through the oceans of routine but rather make something fast, reliable, new, etc. But routine just scares away. Sthu.
