Re: bash shell startup files
Bruce Dubbs wrote: 2) /etc/profile.d/extrapaths.sh uses the [ -d /usr/local/sbin -a $EUID -eq 0 ] construction, but the -a doesn't work in all shells (try posh). Suggestion: [ -d /usr/local/sbin ] [ $EUID -eq 0 ] The title of the section is Bash Shell Startup Files. I prefer to leave this alone, although I wouldn't be opposed to making the comment in the descriptive text that some constructs in the files are Bash specific and may not run in all shells without modification. After all, they won't run at all in tcsh. Correct, tcsh does not attempt to use /etc/profile as its startup file (FIXME: the book currently says nothing about csh startup files). However, /etc/profile is read by all shalls that position themselves as Bourne-compatible, so it must contain no bashisms. 4) It should be mentioned that umask (as set in the book) doesn't work for non-shell logins (e.g., scp or svn-over-ssh). A recommendation to use pam-umask (http://ftp.debian.org/debian/pool/main/p/pam-umask/pam-umask_0.04.tar.gz) may be more suitable. In my opinion, pam is a PITA. It is useful in multi-user environments, but shouldn't be a default for BLFS. The top of the section does already says that non-login shells normally only run ~/.bashrc. Perhaps more examples may be useful, but we can't really cover every circumstance where a non-login shell is run. That's why this module has been created. I do not propose to make this the default, but IMHO not everyone knows about this solution - so why not mention it? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: bash shell startup files
Alexander E. Patrakov wrote: Bruce Dubbs wrote: 2) /etc/profile.d/extrapaths.sh uses the [ -d /usr/local/sbin -a $EUID -eq 0 ] construction, but the -a doesn't work in all shells (try posh). Suggestion: [ -d /usr/local/sbin ] [ $EUID -eq 0 ] The title of the section is Bash Shell Startup Files. I prefer to leave this alone, although I wouldn't be opposed to making the comment in the descriptive text that some constructs in the files are Bash specific and may not run in all shells without modification. After all, they won't run at all in tcsh. Correct, tcsh does not attempt to use /etc/profile as its startup file (FIXME: the book currently says nothing about csh startup files). However, /etc/profile is read by all shalls that position themselves as Bourne-compatible, so it must contain no bashisms. I'm afraid I disagree. When you lower something to the least common denominator, there is no progress. One of the objectives of the book is education. Showing different constructs is educational. If the user changes the login shell, solving any problems will also be educational. I have no problem saying that using a shell other than bash will probably require some adjustments to the config files. 4) It should be mentioned that umask (as set in the book) doesn't work for non-shell logins (e.g., scp or svn-over-ssh). A recommendation to use pam-umask (http://ftp.debian.org/debian/pool/main/p/pam-umask/pam-umask_0.04.tar.gz) may be more suitable. In my opinion, pam is a PITA. It is useful in multi-user environments, but shouldn't be a default for BLFS. The top of the section does already says that non-login shells normally only run ~/.bashrc. Perhaps more examples may be useful, but we can't really cover every circumstance where a non-login shell is run. That's why this module has been created. I do not propose to make this the default, but IMHO not everyone knows about this solution - so why not mention it? An easier solution would be to tell the user to put the umask statement in ~/.bashrc. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
bash shell startup files
Hello, the bash shell startup files section can be improved: 1) /etc/profile tests for EUID=0 in two different ways: |if [ $EUID -eq 0 ] ; then pathappend /sbin:/usr/sbin unset HISTFILE fi| |if [[ $EUID == 0 ]] ; then PS1=$RED\u [ $NORMAL\w$RED ]# $NORMAL else PS1=$GREEN\u [ $NORMAL\w$GREEN ]\$ $NORMAL fi | Please remove the == construction, it is completely unneeded here, -eq works just fine. Also, # can be replced with \$, too. 2) /etc/profile.d/extrapaths.sh uses the [ -d /usr/local/sbin -a $EUID -eq 0 ] construction, but the -a doesn't work in all shells (try posh). Suggestion: [ -d /usr/local/sbin ] [ $EUID -eq 0 ] 3) /etc/profile.d/readline.sh is completely unneeded - readline-5.2 looks in /etc/inputrc by default. 4) It should be mentioned that umask (as set in the book) doesn't work for non-shell logins (e.g., scp or svn-over-ssh). A recommendation to use pam-umask (http://ftp.debian.org/debian/pool/main/p/pam-umask/pam-umask_0.04.tar.gz) may be more suitable.|| -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: bash shell startup files
Alexander E. Patrakov wrote: Hello, the bash shell startup files section can be improved: 1) /etc/profile tests for EUID=0 in two different ways: |if [ $EUID -eq 0 ] ; then pathappend /sbin:/usr/sbin unset HISTFILE fi| |if [[ $EUID == 0 ]] ; then PS1=$RED\u [ $NORMAL\w$RED ]# $NORMAL else PS1=$GREEN\u [ $NORMAL\w$GREEN ]\$ $NORMAL fi | Please remove the == construction, it is completely unneeded here, -eq works just fine. Also, # can be replced with \$, too. Although you are correct about unneeded, I think it should remain as a demonstration of different techniques. 2) /etc/profile.d/extrapaths.sh uses the [ -d /usr/local/sbin -a $EUID -eq 0 ] construction, but the -a doesn't work in all shells (try posh). Suggestion: [ -d /usr/local/sbin ] [ $EUID -eq 0 ] The title of the section is Bash Shell Startup Files. I prefer to leave this alone, although I wouldn't be opposed to making the comment in the descriptive text that some constructs in the files are Bash specific and may not run in all shells without modification. After all, they won't run at all in tcsh. 3) /etc/profile.d/readline.sh is completely unneeded - readline-5.2 looks in /etc/inputrc by default. But it does show how to change things if the default is not used. Again, a comment that it is unnecessary if using the defaults wouldn't hurt, but I think the example should remain. 4) It should be mentioned that umask (as set in the book) doesn't work for non-shell logins (e.g., scp or svn-over-ssh). A recommendation to use pam-umask (http://ftp.debian.org/debian/pool/main/p/pam-umask/pam-umask_0.04.tar.gz) may be more suitable. In my opinion, pam is a PITA. It is useful in multi-user environments, but shouldn't be a default for BLFS. The top of the section does already says that non-login shells normally only run ~/.bashrc. Perhaps more examples may be useful, but we can't really cover every circumstance where a non-login shell is run. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: bash shell startup files
On 9/30/07, Bruce Dubbs [EMAIL PROTECTED] wrote: Alexander E. Patrakov wrote: Hello, the bash shell startup files section can be improved: 1) /etc/profile tests for EUID=0 in two different ways: |if [ $EUID -eq 0 ] ; then pathappend /sbin:/usr/sbin unset HISTFILE fi| |if [[ $EUID == 0 ]] ; then PS1=$RED\u [ $NORMAL\w$RED ]# $NORMAL else PS1=$GREEN\u [ $NORMAL\w$GREEN ]\$ $NORMAL fi | Please remove the == construction, it is completely unneeded here, -eq works just fine. Also, # can be replced with \$, too. Although you are correct about unneeded, I think it should remain as a demonstration of different techniques. For the ==, I agree. For the #, I think it makes more sense to show that \$ expands to '#' for root. 3) /etc/profile.d/readline.sh is completely unneeded - readline-5.2 looks in /etc/inputrc by default. But it does show how to change things if the default is not used. Again, a comment that it is unnecessary if using the defaults wouldn't hurt, but I think the example should remain. I agree with Alexander here. See readline(3), INITIALIZATION FILE section. Readline checks for ~/.inputrc, then falls back to /etc/inputrc unless INPUTRC is set. I see what you mean about showing how the variable can be used, but I think this is beyond the scope of what most people will care about. There are tons of other environment variables that we don't discuss, and I think most users will be entirely happy with the readline default behavior. In LFS, it is also suggested that `info readline' is read, and users would be able to find this information there. What I'd like to see in LFS instead of suggesting that the contents of /etc/inputrc can be copied to the user's ~/.inputrc is a suggestion to use $include /etc/inputrc. But that's not a BLFS discussion. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Bash shell startup files
Hi all, I'm not certain of something. Do we expect *all users* to perform the steps shown in the Bash shell startup files? I know I don't do them. I have my own way of setting up /etc/profile, et. all. And this makes the JDK instructions related to the CLASSPATH broken. I'm not a big fan of this pathprepend and pathappend stuff. In fact, I'd like to remove it in favor of something that isn't BLFS specific. I'm wondering if the Bash Shell Startup Files shouldn't be listed in the required dependencies? I don't recall anything in BLFS as being mandatory, yet the JDK instructions simply *assume* that folks followed the Bash Shell startup stuff. I'm looking for an answer, as I think we need to add JUnit to the book as it is now required by Apache Ant. And Apache Ant is now a required dependency for FOP (Ant is no longer in the FOP source tree). The Junit install dir and the .jar file need to be in the CLASSPATH and I'm not sure how to handle this. -- Randy rmlscsi: [bogomips 1003.28] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 13:23:00 up 13 days, 11:22, 1 user, load average: 0.35, 0.22, 0.09 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Bash shell startup files
El Jueves, 22 de Marzo de 2007 19:30, Randy McMurchy escribió: Hi all, I'm not certain of something. Do we expect *all users* to perform the steps shown in the Bash shell startup files? I know I don't do them. I have my own way of setting up /etc/profile, et. all. To me that section is only an example about how to improve bash configuration, but it is not mandatory and we should not force users to follow it by the letter. That is applicable also to the rest of the After LFS Configuration Issues chapter., IMHO And this makes the JDK instructions related to the CLASSPATH broken. I'm not a big fan of this pathprepend and pathappend stuff. In fact, I'd like to remove it in favor of something that isn't BLFS specific. I agree. I'm wondering if the Bash Shell Startup Files shouldn't be listed in the required dependencies? No, please. I don't recall anything in BLFS as being mandatory, yet the JDK instructions simply *assume* that folks followed the Bash Shell startup stuff. Thus bad assumption, IMHO. I'm looking for an answer, as I think we need to add JUnit to the book as it is now required by Apache Ant. And Apache Ant is now a required dependency for FOP (Ant is no longer in the FOP source tree). The Junit install dir and the .jar file need to be in the CLASSPATH and I'm not sure how to handle this. The standard CLASSPATH=$CLASSPATH:/path/to/jar_file should work and be enough. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Bash shell startup files
M.Canales.es wrote these words on 03/22/07 14:19 CST: The standard CLASSPATH=$CLASSPATH:/path/to/jar_file should work and be enough. Thanks for the input, Manuel. I too am in favor of showing *what* needs to be done, not *how* it should be done (when it comes to setting up login shell scripts). And just for the record, JUnit wants its installation directory in the CLASSPATH also (required to run the regression tests on JUnit, anyway). So, it would be this: CLASSPATH=$CLASSPATH:/path/to/junit-4.1.jar:/usr/share/junit-4.1 (assuming JUnit is installed in /usr/share/junit-4.1) -- Randy rmlscsi: [bogomips 1003.28] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 14:29:01 up 13 days, 12:28, 1 user, load average: 0.14, 0.06, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Section: The Bash Shell Startup Files - PATH=/your/head/asplode
Hello BLFS Development! It's been a while since my first post here, so I figured I would add some of my observations since 6.2 has been released. I'll only be discussing the section The Bash Shell Startup Files today, since it is still fresh in my mind from my most recent build. First, a quick bug in the book: tinker_term.sh is still referenced in the sample /etc/bashrc, which may be confusing to newcomers. The ticket is here: http://wiki.linuxfromscratch.org/blfs/ticket/2314#preview But the main reason I'm posting to the mailing list today is to discuss the way the scripts set the environment variable PATH. As is standard convention, it is done through /etc/profile, but there are a few flaws that I have come to realize relating to using something as simple as su. When I'm installing packages, I tend to use su constantly so that I can switch in and out of root access to the filesystem. I'm sure lots of you do this. Others among you, notably the jhalfs developers, might make more use of sudo. I don't use sudo so I don't know how this affects it. In BLFS, there is no mention of /etc/login.defs. On a default lfs system, login.defs provides a basic PATH for users and root. When su is used, it draws your PATH from this file, completely avoiding /etc/profile.d/extrapaths.sh. Of course, this isn't the case when you use 'su -', since it then parses the profile of the user, although this is not the way people tend to call su when installing packages - it's not ideal to have to cd back to where you were. With that said, what is the problem? By default, /usr/local is completely ignored. This is because it is only configured in /etc/profile.d/extrapaths.sh, and since su is gathering it's PATH information from /etc/login.defs it gets the standard default of PATH=/sbin:/bin:/usr/sbin:/usr/bin. The same semantics caused a simular bug with umask. My user (jonathan, group jonathan) got the default umask of 002 because of his uid being equal to gid. After compiling gpm and su-ing, I installed gpm user and group read-writable as root:root. Why? Because umask settings are controlled through /etc/profile, and su ignores it. The first fix I want to suggest breaks standard convention. The only way I see this consistantly working without running scripts multiple times would be to set PATH with /etc/bashrc instead of /etc/profile, and remove the settings from /etc/login.defs all together. This would provide root, no matter how you logged in, with the intended default PATH. The other fix method would be to set the PATH in /etc/login.defs as well, but I personally hate having multiple definitions throughout a system for the same thing - it's just harder to maintain. Plus, there might be a problem with this method if you use PAM. On my BLFS-6.1 system the PATH settings in login.defs are completely ignored when I use PAM, though that may be my specific configuration as I'm no longer using the defaults from the book. I have yet to install PAM on BLFS-6.2 so I could be wrong, but currently I consider this method with PAM unreliable. I don't like the fixes that I'm suggesting, but I also don't like this behavior, and I personally consider this to be a bug. I also don't see any other ways to fix it. Any thoughts? Jonathan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Section: The Bash Shell Startup Files - PATH=/your/head/asplode
On 3/16/07, Jonathan Oksman [EMAIL PROTECTED] wrote: When I'm installing packages, I tend to use su constantly so that I can switch in and out of root access to the filesystem. I'm sure lots of you do this. Others among you, notably the jhalfs developers, might make more use of sudo. I don't use sudo so I don't know how this affects it. In BLFS, there is no mention of /etc/login.defs. On a default lfs system, login.defs provides a basic PATH for users and root. When su is used, it draws your PATH from this file, completely avoiding /etc/profile.d/extrapaths.sh. Of course, this isn't the case when you use 'su -', since it then parses the profile of the user, although this is not the way people tend to call su when installing packages - it's not ideal to have to cd back to where you were. With that said, what is the problem? By default, /usr/local is completely ignored. This is because it is only configured in /etc/profile.d/extrapaths.sh, and since su is gathering it's PATH information from /etc/login.defs it gets the standard default of PATH=/sbin:/bin:/usr/sbin:/usr/bin. This is actually because of shadow's su and there's not much we can do about it. It always drops PATH and sets it to /bin:/usr/bin unless set with ENV_PATH or ENV_SUPATH in /etc/login.defs. Coreutils' su doesn't have this behavior, but also doesn't support PAM. Sudo also doesn't do this, so you may want to look into that. The same semantics caused a simular bug with umask. My user (jonathan, group jonathan) got the default umask of 002 because of his uid being equal to gid. After compiling gpm and su-ing, I installed gpm user and group read-writable as root:root. Why? Because umask settings are controlled through /etc/profile, and su ignores it. I'm not a huge fan of that default umask, but I suggest you set a sane default umask for whatever user is doing the building. I actually expect that umask gets set to 022 (the default) after you su. But some packages aren't smart about how they create files for installation and don't set the permissions. I would bet that gpm's Makefile simply copies the created files to the install location. Most autotooled packages use install and specify -mmode for the installed files. The first fix I want to suggest breaks standard convention. The only way I see this consistantly working without running scripts multiple times would be to set PATH with /etc/bashrc instead of /etc/profile, and remove the settings from /etc/login.defs all together. This would provide root, no matter how you logged in, with the intended default PATH. I don't really agree with setting PATH from a non-login shell, but you've certainly highlighted the spot where this convention breaks. The other fix method would be to set the PATH in /etc/login.defs as well, but I personally hate having multiple definitions throughout a system for the same thing - it's just harder to maintain. Yeah, that sucks, but I think that's how it is using shadow's su. Plus, there might be a problem with this method if you use PAM. On my BLFS-6.1 system the PATH settings in login.defs are completely ignored when I use PAM, though that may be my specific configuration as I'm no longer using the defaults from the book. I have yet to install PAM on BLFS-6.2 so I could be wrong, but currently I consider this method with PAM unreliable. It works differently with PAM. If you have pam_env.so in your su configuration, it will read settings from /etc/security/pam_env.conf and you can set the default path there. http://www.linuxfromscratch.org/blfs/view/svn/postlfs/shadow.html I don't like the fixes that I'm suggesting, but I also don't like this behavior, and I personally consider this to be a bug. I also don't see any other ways to fix it. Any thoughts? I agree that not maintaining PATH sucks. I'd look at sudo for the quick fix solution. Anything else short of patching shadow's su will have undesired behavior in a different way. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Section: The Bash Shell Startup Files - PATH=/your/head/asplode
On 3/16/07, Dan Nicholson [EMAIL PROTECTED] wrote: On 3/16/07, Jonathan Oksman [EMAIL PROTECTED] wrote: The same semantics caused a simular bug with umask. My user (jonathan, group jonathan) got the default umask of 002 because of his uid being equal to gid. After compiling gpm and su-ing, I installed gpm user and group read-writable as root:root. Why? Because umask settings are controlled through /etc/profile, and su ignores it. I'm not a huge fan of that default umask, but I suggest you set a sane default umask for whatever user is doing the building. I actually expect that umask gets set to 022 (the default) after you su. But some packages aren't smart about how they create files for installation and don't set the permissions. I take that back. umask is persistent across su, it seems. I think the right thing to do is still to set the umask to the default for whatever user is building/installing packages. I would bet that gpm's Makefile simply copies the created files to the install location. Most autotooled packages use install and specify -mmode for the installed files. This is still true, though. Most packages set the right permissions on their own and don't rely on umask. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Tiny typo to fix in 7.9. The Bash Shell Startup Files
Kim McCall wrote: There is a place 2/3 of the way down the page that reads This results in in a final locale setting of ... Thanks very much for the report. Fixed in r6465. I'll be merging this and some other typo fixes into the 6.1 branch shortly. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Section 7.9 - The Bash shell startup files
On Thu, Jun 23, 2005 at 02:02:57AM -0600, Archaic wrote: Anyone else have any comments? Matt? Randy? -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Section 7.9 - The Bash shell startup files
On Sat, Jun 25, 2005 at 01:39:55PM -0400, Jeremy Huntwork wrote: Hrm. This doesn't really seem to do it for me either, though. I think something needs to show that 'info program-name' is a command to run. Of course in xml it will be commandinfo program-name/command. I just didn't think I needed to be that pedantic here. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Section 7.9 - The Bash shell startup files
Archaic wrote: Sorry, I thought I'd already replied to this :( Issue 1: I really can't tell which method of referencing an 'info' page is better. Issue 2: A base /etc/profile below sets sed s/A/The/ Agreed. Issue 3: such locales are not supported by LFS in any way. suggested: such locales are not yet supported by LFS. Agreed. Cheers, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Section 7.9 - The Bash shell startup files
Referencing: http://www.linuxfromscratch.org/lfs/view/testing/chapter07/profile.html Issue 1: the following text sounds odd to me: ### For more information, see info bash - Nodes: Bash Startup Files and Interactive Shells. ### There is only one other place that I found with a quick grep where a specific info section is referred to and that is the inputrc page (which a textual change submission is already underway). In that one the following format is suggested: ### bash info page under the Readline Init File section. ### I'm starting to think perhaps the format for both should be: info program-name under the node-name section Issue 2: A base /etc/profile below sets sed s/A/The/ Issue 3: such locales are not supported by LFS in any way. suggested: such locales are not yet supported by LFS. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
RE: Section 7.9 - The Bash shell startup files
Issue 1: the following text sounds odd to me: ### For more information, see info bash - Nodes: Bash Startup Files and Interactive Shells. ### snip Issue 3: such locales are not supported by LFS in any way. suggested: such locales are not yet supported by LFS. Issue 1: I like it the way it is. ;) Issue 2: ? Issue 3: Sounds good. :) Dave -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
