Re: bash in /usr/local/bin?
Terry Lambert on 2001-08-11 (Sat) at 12:47:01 -0700: Garance A Drosihn wrote: As to Jason's situation, I also like to use bash as my shell even when I am root. However, I do not want to muck around with the port for 'bash', or do anything else to move where bash is or how it's built. So, the way I decided to handle it was to add the following lines in the /root/.login file: if ( -x /usr/local/bin/bash ) then # echo Switching to bash exec /usr/local/bin/bash -login endif So, strictly speaking /bin/csh is still the default shell for root, but the effect for me is that I automatically get bash whenever I log in. This seems to work fine for me, and I am not aware of any problems which have been caused by this trick in the few years that I have been using it. Add setenv SHELL /usr/local/bin/bash, and only do your trick in the initial interactive login shell, and your logins will be faster, and you will get the right (for those definitions of right which include intentional use of bash 8-)) shell when you shell out of vi or other programs. You may also want to restrict it so that only interactive login sessions cause bash to be invoked. To summarise: if ( $tty != ) then if ( -x /usr/local/bin/bash ) then setenv SHELL /usr/local/bin/bash exec /usr/local/bin/bash -login endif endif (There may be a more elegant way to check for shell interactivity in csh, and if there is I'd like to know about it, please. :-) -- V To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Tue, Aug 14, 2001 at 01:23:40PM +0200, Johann Visagie wrote: if ( $tty != ) then (There may be a more elegant way to check for shell interactivity in csh, and if there is I'd like to know about it, please. :-) I've used if ($?USER == 0 || $?prompt == 0) in the past. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
At 1:23 PM +0200 8/14/01, Johann Visagie wrote: You may also want to restrict it so that only interactive login sessions cause bash to be invoked. To summarise: if ( $tty != ) then if ( -x /usr/local/bin/bash ) then setenv SHELL /usr/local/bin/bash exec /usr/local/bin/bash -login endif endif (There may be a more elegant way to check for shell interactivity in csh, and if there is I'd like to know about it, please. :-) If you check in the standard (default) .cshrc, it has the lines: if ($?prompt) then # An interactive shell -- set some stuff up set filec set history = 100 set savehist = 100 set mail = (/var/mail/$USER) endif So I suspect that's the check I should use in .login -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
David O'Brien writes: | On Tue, Aug 14, 2001 at 01:23:40PM +0200, Johann Visagie wrote: |if ( $tty != ) then | | (There may be a more elegant way to check for shell interactivity in csh, and | if there is I'd like to know about it, please. :-) | | I've used if ($?USER == 0 || $?prompt == 0) in the past. I've used 'tty' to tell me for more info 'man tty'. a21p% echo hello | tty echo hi not a tty a21p% tty echo hi /dev/ttypg hi a21p% Don't know if this has been mentioned since I generally ignore things about bash. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
I said I'd drop it, but apparently there are people that don't understand the dinosaur mentality of certain organizations such as DOD, DISA/DECC, OSD, DARPA, USA, USN, USAF, and USMC. If it's not in the base setup, on a production box, you can't use it. *Huh* This policy must have been implemented in the last 12 months, since the last big contract my previous company did with the USMC, we had a couple dozen Sun workstations, and I had all sorts of 'non-standard' software installed on it, including most of the GNU utilities, gzip, etc Prior to this contract, we did similar work for the Army and there were few restrictions to the software we wrote for them. Everything must be kept in it's ORIGINAL install location, It's wherever the installation tools installed them into. In the case of the Solaris boxes, I think the stuff was all in /usr/local/bin, which suprised me because I was used to 'optional' software going in /opt/*/bin due to the packaging details that most pre-packaged 3rd party software I've gotten for Solaris boxes. otherwise you MUST justify it and ask DISA/DECC for a waiver, which in itself, is a pain in the ass, and in many cases, not likely to happen due to dinosaur mentality. Again, as a former USMC/DOD contracter, this was *certainly* not the case. FreeBSD is getting military contracts now. FreeBSD has been used in military contracts for *years* now. Maybe it wasn't as high-profile as the TrustedBSD work, but it's been in use by the Government for quite a long time (and in a state where the people involved had direct knowledge that FreeBSD was being used). I'm sure there are equally restrictive environments for computers and operating systems in *EVERY* country, but I speak from my personal experience with the dinosaurs at DOD. At DOD, *EVERY* copy of FreeBSD will be subject to what I am saying. In the Sun environment in which I did my last DOD contract at, if tcsh wasn't in /bin, I wouldn't have been able to use it. That's how backwards they are. Again, my suspicion is that you're dealing with some very weird folks at your installation. My experience was quite different, and involved some machines that were running hardened versions of Solaris on secret networks, although I was never allowed to use those machines once they were installed there. :) :) Things aren't as bad as you're experience might suggest Nate ps. Amazingly enough, the software we had to integrate with (being used by both branches) was *riddled* with remote exploit and DoS bugs, but unfortunately they could not be fixed and still stay 'compliant'. The protocol was set in stone (gotta stay compatible), and some of the DoS bugs were due to the incredibly stupid protocol being used. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
Nate Williams wrote: Umm, Terry. There was no 'free' tar. Back in the 386BSD days, when we were looking for a free tar, I contacted Andy Tanenbaum (of Minix) and got permission to use it, since we didn't have one. However, it was voted down as being 'too simple', so we opted for the GNU one. There isn't a BSD or public domain version of tar anywhere to be found, unless you consider 'pax' running in tar emulation mode acceptable. (I certainly don't.) I was just going to say pax... The tar program is really trivial to write: it's user space code, and you can run all sorts of fancy debug tools on it, and get a nice core dump to post mortem when it falls over, if you don't want to run it in a source level debugger, which will tell you the precise line of code the failure occurred on. In general, user space code is at least an order of magnitude easier to write. 8-). In any case, what don't you like about pax, other than it's not GNU tar? The same story exists with grep. That's actually not true; there are three different implemetnations of the Boyer-Moore algorithm based grep tools in the comp.unix.sources archives. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
The Anarcat wrote: [Foul-mouthed anti-gummint drivel deleted] Actually, it is up to us to resolve this. I don't think you understand how DOD operates. The vendor makes the changes, not DOD. Not the admin. And FreeBSD is the *vendor*? I don't think so. At least I don't hope so. If I'm mistaken, slap me Consider yourself slapped. The FreeBSD project is the only DOD-approved vendor of FreeBSD. Until the core team says otherwise. Moving the non-GPL shells to /bin is a trivial request that can solve problems that you obviously don't understand. Then we could also answer a trivial request such as making apache part of the base system! If the DOD need a webserver, they're screwed? They panic? What the heck is that? And why should we care about such d**kheads? No, they aren't screwed. They don't panic. They simply say screw FreeBSD and just call Sun, which does have Apache in the base distribution, as well as the shells where the admin is allowed to use them, and doesn't give them a bunch of anti-gummint drivel. Wasn't the DOD using NT? Not for anything serious. Key to this is an admin-friendly environment designed to get around the pre-cambrian attitudes that prevent DOD admins from using standard tools just because it's in the wrong place on the disk array or because it's considered a third-party option, or even worse: freeware [h! step away from the keyboard, son. you going to prison, boy!]. Bash standard? Funny. How many users of FreeBSD? How many users of Linux? How many people using csh? How many people using bash? Besides the fact that you don't reason well, you don't read too well. bash is GPL, it wouldn't qualify for the tree. zsh is open, and has the features of bash, and could probably be a good substitute. The proposition here doesn't involve any specific shell, it's a usability issue. I had very good comments on the easiness (sp?) ppl have installing third party apps in the install process. And the ports collection, and the packages, etc... FreeBSD is very admin friendly, IMHO. Only when the admin has the ability to install third-party standard tools. Try thinking outside the box sometime. If you want a traditional unix, I think there is still a PDP-11 emulator and DL01 image of V7 at gatekeeper.dec.com. Yeah. Let's go with the New Technology: NT. All these buzzwords and semantics are messing things up here. It's not a matter of tradition, it's a matter of license (bash is GPL, FBSD is BSD-licensed), and functionality (bash != sh). See also the comment about resistance to have perl in the base system. perl is in the base system. and again, you don't read too well, i haven't said a nice word in this entire thread about bash, and others have noted the GPL. Linux have bash in the base system simply because there's no other free close relative to sh around. that was a rather inane statement... ever read the BSD license? I'm more for an evolutionary unix where the idea of what's standard changes to reflect the needs of it's admins and users in diverse environments. As much as I appreciate evolution, I think this mentality is exactly the thing that makes us pull away from support from old hardware. That's a shame. how does moving defacto-standard userland items into the basic system effect the kernel? you lost me there. going nowhere due to outdated beliefs oh, but that belongs in /usr/local/bin. Again, it's not a belief. It's a philosophy that is behind FreeBSD. a belief that keeps freebsd out of some hardcore, high-dollar markets. Anyways, this has probably been burnt to death long time ago, I should not get into this. Yes, and I think you should close and wipe your mouth after your foul-mouthed anti-gummint spewing. Flys are gathering around your tooth. My argument for the trivial move of the non-GPL shells to /bin, so long as they are statically linked, is based on experience in a market in which FreeBSD just got it's foot inside of the door. We have already done this with tcsh. I don't see what the problem is getting the rest of the non-GPL shells into /bin is. I missed something here. Is tcsh GPLed? I don't think so... A quick look at /usr/src/contrib/tcsh gives me 2 matches for GNU, config.guess and config.sub. The rest looks like standard BSD license. Am I wrong? 2:19:01am wahoo(2): where tcsh /bin/tcsh Hey Jethro, who put that there? did you? wasn't me! Maybe it was one of dem damned gummint black heeleechoppers being piloted by ET and Bill Clinton... Please, jim, do not take my comments too harsh. I have a very strong... opinion of the military, and of progress, evolution or whatever you want to call that mad fuite en avant (I don't know the proper idiom in english (this was french)). I'm not taking the comments too harsh. I wouldn't have answered, or, if I had, it would have been far less tongue in cheek. FreeBSD is largely derived
Re: bash in /usr/local/bin?
Steve O'Hara-Smith wrote: On Sun, 12 Aug 2001 17:04:01 -0500 Jim Bryant [EMAIL PROTECTED] wrote: JB I said I'd drop it, but apparently there are people that don't understand the dinosaur mentality of certain organizations such as JB DOD, DISA/DECC, OSD, DARPA, USA, USN, USAF, and USMC. JB JB If it's not in the base setup, on a production box, you can't use it. Everything must be kept in it's ORIGINAL install location, Th obvious solution to this is a 'Military' switch in sysinstall that sets PREFIX to / for all ports. heheh... actually... i've seen military systems that do this... from what i've read here, not many undrestand the actual mindset of the military when it comes to computing. the closest would be the guy who mentioned that since ports are on the CD's that they should be acceptable, this is incorrect. it took me a while to figure out how backwards they really are. this is one of the many reasons that they cannot keep good unix talent around. remember, these are the same people that argued that C and C++ was evil and that only ADA was good for nearly 15 years, until they finally realized they were wrong. let's take a look at the failures of what was supposed to be ADA's swan-song project: the new FAA ATC system... you know... the one that keeps crashing everywhere it's installed. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Mon, Aug 13, 2001 at 04:13:52AM -0500, Jim Bryant wrote: from what i've read here, not many undrestand the actual mindset of the military when it comes to computing. the closest would be the guy who mentioned that since ports are on the CD's that they should be acceptable, this is incorrect. You are making sweeping generalizations. Please stop and be specific which parts of the military. It is correct for the CIA. The CIA[*] will not let you bring in any download bits off the net (or floppies containing them) to compile locally and install. HOWEVER, if the bits come on a CDROM from a commercial vendor, they are OK. So in the FreeBSD case, packages are on the commercial 4-disc set, and thus can be installed. In older days for Solaris, one had to find a CD offering from say Walnut Creek CDROM that contained precompiled versions of GNU bits for Solaris. Again, if it was something their purchasing could buy from a vendor an receive it was OK. -- -- David ([EMAIL PROTECTED]) [*] yes I did my time as a cleared Beltway Bandit To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
DOD/DFAS, as well as DOD/DISA. I find it amazing that the CIA has a more lax policy than DFAS and DISA. David O'Brien wrote: On Mon, Aug 13, 2001 at 04:13:52AM -0500, Jim Bryant wrote: from what i've read here, not many undrestand the actual mindset of the military when it comes to computing. the closest would be the guy who mentioned that since ports are on the CD's that they should be acceptable, this is incorrect. You are making sweeping generalizations. Please stop and be specific which parts of the military. It is correct for the CIA. The CIA[*] will not let you bring in any download bits off the net (or floppies containing them) to compile locally and install. HOWEVER, if the bits come on a CDROM from a commercial vendor, they are OK. So in the FreeBSD case, packages are on the commercial 4-disc set, and thus can be installed. In older days for Solaris, one had to find a CD offering from say Walnut Creek CDROM that contained precompiled versions of GNU bits for Solaris. Again, if it was something their purchasing could buy from a vendor an receive it was OK. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Mon, Aug 13, 2001 at 07:23:26PM -0500, Jim Bryant wrote: DOD/DFAS, as well as DOD/DISA. I find it amazing that the CIA has a more lax policy than DFAS and DISA. The only person I've ever talked to from the CIA was in charge of network security to some degree, and according to him they can't even use FreeBSD, OpenBSD, or NetBSD internally. Everything must come from a central vendor and be supported by a real company, not by mailing lists. I'd call that less lax. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
Joseph Mallett wrote: On Mon, Aug 13, 2001 at 07:23:26PM -0500, Jim Bryant wrote: DOD/DFAS, as well as DOD/DISA. I find it amazing that the CIA has a more lax policy than DFAS and DISA. The only person I've ever talked to from the CIA was in charge of network security to some degree, and according to him they can't even use FreeBSD, OpenBSD, or NetBSD internally. Everything must come from a central vendor and be supported by a real company, not by mailing lists. I'd call that less lax. Then, I'd call it about the same. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
I said I'd drop it, but apparently there are people that don't understand the dinosaur mentality of certain organizations such as DOD, DISA/DECC, OSD, DARPA, USA, USN, USAF, and USMC. If it's not in the base setup, on a production box, you can't use it. Everything must be kept in it's ORIGINAL install location, otherwise you MUST justify it and ask DISA/DECC for a waiver, which in itself, is a pain in the ass, and in many cases, not likely to happen due to dinosaur mentality. I now refer you to the recent news concerning the TrustedBSD project. FreeBSD is getting military contracts now. We need to think ahead to the needs of a whole new class of admin and user, and they are in highly restrictive environments that preclude `mv /usr/local/bin/*sh /bin`. I'm sure there are equally restrictive environments for computers and operating systems in *EVERY* country, but I speak from my personal experience with the dinosaurs at DOD. At DOD, *EVERY* copy of FreeBSD will be subject to what I am saying. In the Sun environment in which I did my last DOD contract at, if tcsh wasn't in /bin, I wouldn't have been able to use it. That's how backwards they are. In answer to your statement, some admins can be fired, even arrested and brought up on charges for doing what you suggest. I'm certain that this happens in countries other than America as well. Joseph Mallett wrote: If these admins can't figure out cp `which bash` /bin and then how to add it to etc/shells and chsh root, then I really question if they should be the kind of people that dictate the future of FreeBSD. 0n Sun, Aug 12, 2001 at 04:32:55AM -0500, Jim Bryant wrote: IMHO, all widely accepted shells should be put in /bin jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Sun, Aug 12, 2001 at 08:38:56PM +0200, Bernd Walter wrote: Yes the sun packages installs into /bin: ticso@cicely22 uname -a SunOS cicely22 5.8 Generic_108528-01 sun4m sparc SUNW,SPARCclassic ticso@cicely22 which bash /bin/bash ticso@cicely22 file /bin/bash /bin/bash: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped It's not the first time that Unix Vendors do very silly things - just I assume you are referring to the dynamically linked attribute. Note that it is not Sun being silly -- the ELF binary ABI *REQUIRES* dynamic linking. A statically linked ELF binary is not ABI compliant. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
# Bash has a license which precludes its inclusion as part # of the base system. [Not that I favor more shells on the root file system, but anyway:] What about gcc and grep? Does the license differ or are these not regarded being part of the base system? We would get rid of them if we could. We keep their source code in a ghetto, since we can't. Any company wanting to get rid of all GPL'ed and other restrictively licensed code in a FreeBSD based binary distribution can simply dike the ghetto out of the build tree, and build a still usable system binary from it, with no restrictively licensed code. Changing grep and tar was an incredibly bad decision. It has the distinction that the old, free code is there in the Attic, and can be recovered, if need be. Umm, Terry. There was no 'free' tar. Back in the 386BSD days, when we were looking for a free tar, I contacted Andy Tanenbaum (of Minix) and got permission to use it, since we didn't have one. However, it was voted down as being 'too simple', so we opted for the GNU one. There isn't a BSD or public domain version of tar anywhere to be found, unless you consider 'pax' running in tar emulation mode acceptable. (I certainly don't.) The same story exists with grep. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
As a preface to this whole thing, I find it higly amusing that you are sending this mail from a Linux box. Of course, for that matter, so am I. (I'm planning on changing that soon.) On Sun, 12 Aug 2001, Jim Bryant wrote: I said I'd drop it, but apparently there are people that don't understand the dinosaur mentality of certain organizations such as DOD, DISA/DECC, OSD, DARPA, USA, USN, USAF, and USMC. If it's not in the base setup, on a production box, you can't use it. Everything must be kept in it's ORIGINAL install location, otherwise you MUST justify it and ask DISA/DECC for a waiver, which in itself, is a pain in the ass, and in many cases, not likely to happen due to dinosaur mentality. You said it yourself. They are a dinosaur. Why should be drag ourselves back to the paleolithic and cater to a very specific problem in our base tree? bash is a nice shell. I use it as my normal shell, but when I drop to single user mode, I *always* end up using /bin/sh. I'm not a fan of csh (tcsh isn't bad though) and I only write shell scripts in /bin/sh. Besides, how often do you need to drop to single user mode and *really* need bash? I now refer you to the recent news concerning the TrustedBSD project. FreeBSD is getting military contracts now. We need to think ahead to the needs of a whole new class of admin and user, and they are in highly restrictive environments that preclude `mv /usr/local/bin/*sh /bin`. And those people that are working there are probably programming in COBOL and Fortran. I'm sure there are equally restrictive environments for computers and operating systems in *EVERY* country, but I speak from my personal experience with the dinosaurs at DOD. At DOD, *EVERY* copy of FreeBSD will be subject to what I am saying. In the Sun environment in which I did my last DOD contract at, if tcsh wasn't in /bin, I wouldn't have been able to use it. That's how backwards they are. In answer to your statement, some admins can be fired, even arrested and brought up on charges for doing what you suggest. I'm certain that this happens in countries other than America as well. Again, this is a problem for you and the DOD to sort out. It should be of no concern to the project. -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Sun, Aug 12, 2001 at 04:54:08PM -0700, Gordon Tetlow wrote: FreeBSD is getting military contracts now. We need to think ahead to the needs of a whole new class of admin and user, and they are in highly restrictive environments that preclude `mv /usr/local/bin/*sh /bin`. And those people that are working there are probably programming in COBOL and Fortran. Sigh. A stupid language war troll. You haven't looked at the Fortran language since 1977 have you? Back to the topic at hand, bash isn't in the root filesystem. Get over it. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Monday 13 August 2001 3:08 am, The Anarcat wrote: [This email contains coarse language due to the absurdity of the thread level we're in. My apologies to those offended. Also, my apologies to the author of the original mail. You have triggered very sensitive areas of my mind. :)] Swearing adds absolutely nothing to your argument, you've devalued your own opinion by giving the impression you're incapable of expressing yourself without resorting to swearing. I personally got sick of it a short way down and gave up reading. -- Andrew Boothman [EMAIL PROTECTED] http://sour.cream.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
Not to be a pain, but can you wrap lines at a more standard 74 columns as opposed to whatever you are currently wrapping them at? Thanks. On Sun, 12 Aug 2001, Jim Bryant wrote: Gordon Tetlow wrote: As a preface to this whole thing, I find it higly amusing that you are sending this mail from a Linux box. Of course, for that matter, so am I. (I'm planning on changing that soon.) Excuse me? FreeBSD wahoo.kc.rr.com 5.0-CURRENT FreeBSD 5.0-CURRENT #18: Fri Aug 10 16:51:25 CDT 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/WAHOO i386 When Netscape comes out with support for FreeBSD again, I'll run native, until then, I, like everyone else using freebsd am stuck using netscape in the COMPATLINUX construct. Please don't make assumptions about an operating environment without understanding the problems of living within that environment. Ah, my apologies. It's much less amusing now. Also, dinosaurs or not, DOD is now an INVESTOR in the FreeBSD system. Name any other group besides maybe BSDI that has provided $1.4 million [USD] to the project. Okay, I don't recall the FreeBSD Foundation getting $1.4 mil. I know that the DOD is sponsoring some TrustedBSD stuff, but where exactly is the money going? We should look towards making FreeBSD the open-source OS of choice in the DOD environment, in which Linux has already made major inroads where FreeBSD isn't even allowed to tread yet. Actually, it is up to us to resolve this. I don't think you understand how DOD operates. The vendor makes the changes, not DOD. Not the admin. Again, I don't see why we should cater to one specific group of people and let them dictate the direction of the project. Another priority item should be making sure we are compatible with such things as the latest versions of Oracle, etc... This is an area in which we can compete head-to-head with the high-dollar stuff. Well, considering that Oracle doesn't publish *anything* for FreeBSD, I doubt there is anything we can do about it. Veritas NetBackup has a FreeBSD client (no server). IBM DB2 has no FreeBSD support. Heck, as you point out Netscape doesn't even make FreeBSD binaries. And you know what? There's squat that the project can do about it. We can't make companies support FreeBSD if they don't want to spend the resources for it. Also, I havn't worked for DOD in a long time, but I have done recent contracts with them, and understand firsthand the BS involved in having to do without tools all unix people, including myself, consider standard, that are not allowed because it's not part of the base install. Moving the non-GPL shells to /bin is a trivial request that can solve problems that you obviously don't understand. Um, bash is GPL. The reason for not putting it in the base system is due to licensing restrictions. We try to use as few GPL'd pieces as possible. After seeing that grep is a GNU tool, I'm almost tempted to try writing a BSD-style grep for the fun/exercise of it. DOD will is a vast new market for FreeBSD, and if we don't think ahead now and consider what will make admins recommend FreeBSD over Linux, Solaris, or HP-UX, then we'll never reach the kind of market penetration that Linux, Solaris, and HP-UX have in the DOD market. Key to this is an admin-friendly environment designed to get around the pre-cambrian attitudes that prevent DOD admins from using standard tools just because it's in the wrong place on the disk array or because it's considered a third-party option, or even worse: freeware [h! step away from the keyboard, son. you going to prison, boy!]. Read my lips (er text, whatever). Bash and other shells are not going to make it into the base FreeBSD OS. The increasing code base does worry me though. I'm not a big fan of adding more and more functionality to the base. I like the very functional, very useful codebase that we currently have. You can do alot more with a base FreeBSD installation than you can with a base Solaris installation (like compile things). I'm more for an evolutionary unix where the idea of what's standard changes to reflect the needs of it's admins and users in diverse environments. Then feel free to take FreeBSD, tweak it and publish it as DODBSD. By all means, the license lets you do it. I may not be one of the big movers, but I think this is why I do what I can to help out with -CURRENT, to move forwards meeting the needs, instead of going nowhere due to outdated beliefs oh, but that belongs in /usr/local/bin. If something after years of use becomes a standard tool, it needs to be moved into the base distribution. I give perl as a prime example of one time that this actually happened, despite the arguments for or against perl, it *IS* a standard tool, and it *IS* expected to be available. And for 99.999% of the users, they could care less if it's in /usr/local or in / And for things that are not in the base system, they belong in /usr/local. That's
Re: bash in /usr/local/bin?
On Sun, 12 Aug 2001, Steve Kargl wrote: On Sun, Aug 12, 2001 at 04:54:08PM -0700, Gordon Tetlow wrote: FreeBSD is getting military contracts now. We need to think ahead to the needs of a whole new class of admin and user, and they are in highly restrictive environments that preclude `mv /usr/local/bin/*sh /bin`. And those people that are working there are probably programming in COBOL and Fortran. Sigh. A stupid language war troll. You haven't looked at the Fortran language since 1977 have you? I forgot to add sarcasm /sarcasm around that. Actually, ADA would probably be more correct. I was born in 1978 btw. -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Sun, Aug 12, 2001 at 09:20:59PM -0700, Gordon Tetlow wrote: After seeing that grep is a GNU tool, I'm almost tempted to try writing a BSD-style grep for the fun/exercise of it. Rather than do that, continue the development of /usr/ports/textproc/freegrep, which was started for exactly the above reason. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Sun, Aug 12, 2001 at 08:15:15PM -0500, Jim Bryant wrote: Actually, it is up to us to resolve this. I don't think you understand how DOD operates. The vendor makes the changes, not DOD. Not the admin. Sigh. If an admin cannot handle /bin/sh long enough to get /usr mounted, they have no business being an admin. And Yes, I am a 100% bash user (I'm also the guy that brought you tcsh in the base system) Bash is my shell, and toor's shell. When I want bash single user, I answer the question of which shell with /usr/local/bin/bash as my / and /usr are the same (there! problem solved for the guy that started this thread). On machines I deal with that have seperate / and /usr, I take the default of /bin/sh and then do the: mount /usr /usr/local/bin/bash dance. Now that isn't such a hard dance now is it? I live it, it can be done. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Sun, Aug 12, 2001 at 09:20:37PM -0700, Gordon Tetlow wrote: After seeing that grep is a GNU tool, I'm almost tempted to try writing a BSD-style grep for the fun/exercise of it. lizzy:/usr/ports/textproc/freegrep# cat pkg-descr This is an implementation of grep(1) intended as a replacement for FreeBSD's GNU grep. GNU grep falls under GPL, while this implementation is under a BSD-friendly licence. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Sun, Aug 12, 2001 at 10:08:40PM -0400, The Anarcat wrote: And FreeBSD is the *vendor*? I don't think so. At least I don't hope so. Actually we *are*. Seen those ISO's up on ftp.freebsd.org?? -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Sun, 12 Aug 2001 17:04:01 -0500 Jim Bryant [EMAIL PROTECTED] wrote: JB I said I'd drop it, but apparently there are people that don't understand the dinosaur mentality of certain organizations such as JB DOD, DISA/DECC, OSD, DARPA, USA, USN, USAF, and USMC. JB JB If it's not in the base setup, on a production box, you can't use it. Everything must be kept in it's ORIGINAL install location, Th obvious solution to this is a 'Military' switch in sysinstall that sets PREFIX to / for all ports. -- Directable Mirrors - A Better Way To Focus The Sun http://www.best.com/~sohara To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
