Slashdot Mirror


BASH 4.0 Released

An anonymous reader writes "The widely used Bourne-Again Shell (BASH) version 4.0 is out. The new major release fixes several remaining bugs in the 3.x releases, and introduces a bunch of new features. The most notable new features are associative arrays, improvements to the programmable completion functionality, case-modifying word expansions, co-processes, support for the `**' special glob pattern, and additions to the shell syntax and redirections. The shell has been changed to be more rigorous about parsing commands inside command substitutions, fixing one piece of POSIX non-compliance. Most of us will probably wait for the distros to test the new version and upgrade gradually, but you always have the option of grabbing the source and compiling it yourself. Enjoy."

459 comments

  1. This is excellent news by Anonymous Coward · · Score: 5, Funny

    Perhaps this year, Linux will be ready for the desktop.

    1. Re:This is excellent news by mrsteveman1 · · Score: 5, Funny

      No, but it'll be ready for the year of the commandline (comes right after year of the hippo).

    2. Re:This is excellent news by multisync · · Score: 5, Insightful

      Perhaps this year, Linux will be ready for the desktop.

      Linux has been ready for the desktop for years. It's just that certain users are not yet ready for Linux.

      --
      I don't care why you're posting AC
    3. Re:This is excellent news by Anonymous Coward · · Score: 4, Funny

      So... when can we expect the year of the L(inux)user?

    4. Re:This is excellent news by sorak · · Score: 1

      Perhaps this year, Linux will be ready for the desktop.

      Linux has been ready for the desktop for years. It's just that certain users are not yet ready for Linux.

      Of course! Linux is ready for the desktop, but the desktop is not yet ready for Linux! We'll have to find those carpenters and tell them to build better desks.

    5. Re:This is excellent news by Tumbleweed · · Score: 1

      Perhaps this year, Linux will be ready for the desktop.

      Yo, dude, don't bash linux!

    6. Re:This is excellent news by morcego · · Score: 5, Insightful

      Linux has been ready for the desktop for years. It's just that certain users are not yet ready for Linux.

      You are too kind. In fact, most users are not ready to operate computers. At all.

      --
      morcego
    7. Re:This is excellent news by machine321 · · Score: 1

      (comes right after year of the hippo).

      I got one of those for Christmas. The hippo, not the year.

    8. Re:This is excellent news by Anonymous Coward · · Score: 0

      Linux users have been ready for girlfriends for years. It's just that certain girlfriends are not ready for Linux users.

      AND THEY NEVER WILL BE!

    9. Re:This is excellent news by Anonymous Coward · · Score: 0

      There's nothing wrong with the PEN and PAPER.

    10. Re:This is excellent news by DiegoBravo · · Score: 2, Insightful

      Most people don't need to operate computers directly. But a lot of people uses them more or less indirectly, for example, when driving a modern car, or when redacting a letter in MS Word. The idea is that people should never have to be ready for (nor aware of) any OS at all.

    11. Re:This is excellent news by morcego · · Score: 2, Informative

      I will give you the car, but not Word. Want it or not, they ARE operating a computer directly when using MS Word.

      --
      morcego
    12. Re:This is excellent news by DiegoBravo · · Score: 0, Redundant

      > I will give you the car, but not Word. Want it or not, they ARE operating a computer directly when using MS Word.

      Just because they're using a keyboard (instead of a steering wheel) and looking a simple monitor (instead of a digital panel with nice LCD screens/GPS/etc)?

      Think about the average secretary... most can't even plug the cable, but anyway manage to write letters.

    13. Re:This is excellent news by beav007 · · Score: 2, Funny

      You got married on Christmas?

    14. Re:This is excellent news by Anonymous Coward · · Score: 0

      I'm smarter than all those l0sers because I pwn at my computer. Most people need to check mail, run office, and maybe play a flash game or two. Their lives don't revolve around a computer enough to worry about linux.

    15. Re:This is excellent news by fireman+sam · · Score: 5, Informative

      This is a placeholder for my reply to your comment. The comment itself has been written on paper using a disposable BIC ballpoint pen. The paper has been posted to the slashdot editors with instructions to replace this placeholder with the comment that is contained on the paper.

      A note to moderators. The comment I have written on the paper is both insightful and informative as well as funny. It would be impossible to consider the comment I have written to be overrated (even if it were rated +100), a troll, or flamebait. So please rate this placeholder accordingly.

      Thank you.

      --
      it is only after a long journey that you know the strength of the horse.
    16. Re:This is excellent news by Anonymous Coward · · Score: 0

      Linux has been ready for the desktop for years. It's just that certain users are not yet ready for Linux.

      You are too kind. In fact, most users are not ready to operate computers. At all.

      This a million times over.

    17. Re:This is excellent news by shokk · · Score: 0, Redundant

      When users stop calling their hard drive "memory" then they will be ready for the computer that's already in front of them. Baby steps, please.

      --
      "Beware of he who would deny you access to information, for in his heart, he dreams himself your master."
    18. Re:This is excellent news by RCL · · Score: 1

      Linux won't be ready for desktop as long as it's not ready for commercial software market.
      Give users the ability to download whatever (Linux) binary they find over the net and run it, without having them learn about package management, dependencies and without requiring them to install/uninstall anything.
      (Yes, I know that would make Linux boxen much less secure. That's the price you pay for freedom of deciding yourself what you want to run).

    19. Re:This is excellent news by TheSunborn · · Score: 1

      So what you are saying is that Linux is ready for the desktop :}

      The last time I downloaded a binary package was postgresql 8.3, and that installed with no problems on Fedora Core 5

    20. Re:This is excellent news by dov_0 · · Score: 1

      So... when can we expect the year of the L(inux)user?

      After several years of the Linux schol student, office worker and Linux OEM retailer.

      Same way Windows got where it is.

      --
      sudo mount --milk --sugar /cup/tea /mouth /etc/init.d/relax start
    21. Re:This is excellent news by moosesocks · · Score: 2, Insightful

      It's gotten a lot better, but there are still gaps that need to be filled in.

      Today, I had to enable printer sharing (via Samba for Windows clients) on my parents' computer, which is running Ubuntu.

      Although the majority of the desktop is very well-integrated, the process for doing this was *extremely* non-obvious.

      --
      -- If you try to fail and succeed, which have you done? - Uli's moose
    22. Re:This is excellent news by Anonymous Coward · · Score: 1, Insightful

      Somebody needs to learn the difference between primary and secondary memory. Hint: drives *are* memory.

      But yeah, most people are right that it's memory, but not for the reasons they think they are.

    23. Re:This is excellent news by thefekete · · Score: 3, Funny

      In fact, most users are not ready to operate computers, et al.

      Fixed it for you...

      --
      The cool things is to have windows that bounce up and down like a good tits.
    24. Re:This is excellent news by zobier · · Score: 1

      There's nothing wrong with the PEN and PAPER.

      Except that there's billions of people who would like to use it.
      The queue for the use of the PEN would be enormous let alone
      that we would run out of the INK and space on the PAPER.

      --
      Me lost me cookie at the disco.
    25. Re:This is excellent news by Anonymous Coward · · Score: 0

      Nor Linux for them...

    26. Re:This is excellent news by morcego · · Score: 1

      So, what you are saying is just because I can make [ITEM] work, I should be able to operate it ?

      Please replace [ITEM] for whatever you want: gun, airplane, explosive, my neighbor's wife, motorcycle etc.

      --
      morcego
    27. Re:This is excellent news by pjt33 · · Score: 1

      It's a great plan. Makes it really easy to remember the anniversary.

    28. Re:This is excellent news by x2A · · Score: 1

      dude... you're like, killing trees to make that paper, and octipusses to make the ink... if you carry on, you're gonna drown us all in global warming risen sea levels, even accounting for the drop of sea level that comes from taken so much of the ink out

      --
      The revolution will not be televised... but it will have a page on Wikipedia
    29. Re:This is excellent news by x2A · · Score: 1

      "There's nothing wrong with PEN and TELLER"

      How's that relevant?

      --
      The revolution will not be televised... but it will have a page on Wikipedia
    30. Re:This is excellent news by x2A · · Score: 1

      Yeah because the desktop users that linux is/isn't ready for are all about running postgresql.

      (please don't read my point as me having any interest in who linux is or isn't ready for. It does what I want, and that's what matters to me)

      --
      The revolution will not be televised... but it will have a page on Wikipedia
    31. Re:This is excellent news by Patch86 · · Score: 1

      I'm posting this from an Ubuntu PC. When I want to use some software, I go to their website and click on the "download for Ubuntu" button. I then click open, and follow the prompts. It is then installed. That is pretty much exactly as many steps as installing software for Windows by downloading and running the .exe installer. (This is assuming its not in the "Add/Remove..." menu and it's repositories, in which case its just tick the box and click OK.)

      I've never had to give a second thought to dependencies even once, since it deals with that itself. The only thing I've ever had to install is the software itself, the same as for Windows.

      As long as you use a major mainstream distro, you should never have to work any harder than you do with Windows.

    32. Re:This is excellent news by SCHecklerX · · Score: 1

      Dad is on ubuntu as of last weekend, and loving it. Having a stable system that 'just works' is great. Being able to use synaptic to add and remove stuff is also great for him. It was an easy transition, as he was already using Firefox and Open Office. Little things, like safely unmounting USB drives (he uses them a lot) work *BETTER* and with a much more intuitive interface in Gnome than they ever did in windows. Networking, his HP printer/scanner, etc....all just WORKED out of the box. His last remaining issue is to figure out gnucash, or run quicken under wine. That was one area I couldn't offer much help with, since I don't use that particular piece of software, but he's having fun experimenting with gnucash and learning how he can use it.

      Not only is linux ready. It is the best choice in most cases (windoze is the platform if you are a gamer, I guess). Did I mention my girlfriend did this transition on her own a couple of months ago as well? Originally because she liked tetravex on my laptop. So she used wubi, and now boots to that more often than windows.

    33. Re:This is excellent news by Anonymous Coward · · Score: 0

      I'm sorry, what? When you design software (as when you design any end user product), your goal is to make it palatable to users such that they would actually want to USE your software. What is this 'certain users are not ready for Linux' garbage?

      If your operating system is still too difficult to use and incapable of providing the features and configurability that users of other systems have come to expect, then your operating system is doing something wrong, and not the other way around.

      Your mindset is the same 'User Error'/'RTFM' one that has plagued the software industry from its onset. Start designing usable software, take responsibility for your own failings, and then you'll never again have to blame the user for their incompetence.

    34. Re:This is excellent news by Kiaser+Zohsay · · Score: 1

      "There's nothing wrong with PEN and TELLER"

      How's that relevant?

      I disagree. There is something very wrong with those guys. They're crazy.

      --
      I am not your blowing wind, I am the lightning.
    35. Re:This is excellent news by rokknroll · · Score: 1

      In fact, most users are not ready to operate computers, et cetera .
      Fixed it for you...
      "Et Al" means and the others...doesnt make sense in context...fixed that for ya.

      --
      billy pilgrim *has* become unstuck in time!
    36. Re:This is excellent news by rokknroll · · Score: 1

      but....all IT staff are by definition anti-social , failed , potentially mass-killing misanthropes, its why we got into this field in the first place surely?

      And besides, its either a bug or a "feature", its never our fault.

      When a user can spend half a day not being productive before reporting that "her keyboard doesnt work",and upon invetigation she had caps on, then yes, PEBKAC/RTFM.

      --
      billy pilgrim *has* become unstuck in time!
    37. Re:This is excellent news by tom17 · · Score: 1

      Little things, like safely unmounting USB drives (he uses them a lot) work *BETTER* and with a much more intuitive interface in Gnome than they ever did in windows.

      I have to call this one, as I got bitten by it this morning... (wife complaint)

      How is right clicking the icon and choosing "unmount" any better than right clicking the "safely remove" icon?

      On both Linux and Windows, you have to pro-actively perform an action to remove a stick. This must be learned on both os's, BUT it's all in the wording. "Unmount" doesn't mean a whole lot to a non-techie, "Safely remove" makes much more sense.

      This is not a gripe about the effectiveness of the removal functions, by the way, just a comment on the intuitiveness of the wording.

      Tom...

    38. Re:This is excellent news by metamatic · · Score: 1

      Unix is like animal porn: it's not for everybody.

      --
      GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
    39. Re:This is excellent news by tom17 · · Score: 1

      Well, so long as you are not waiting for hundreds of megs to clear from the buffers, but if you do a large copy to the external device, you don't know if it has finished buffering or not unless you safely unmount.

      I guess it depends how big the disk buffers are...

    40. Re:This is excellent news by Patch86 · · Score: 1

      I was not aware there even was a Linux version of iTunes. If you're talking about running non-native software under an emulator or compatibility layer its going to be far more labour intensive- and that'd be true doing the same in Windows too.

      To make Ubuntu play DVDs and rip to MP3s, all I need to do is setup "Medibuntu" (I think its called). Its a single, one-time only thing the first time you set up a computer, and I'd say no more arduous than the hours upon hours of Microsoft Windows Updates you have to run the first time you set up XP.

  2. csh syntax mode? by Anonymous Coward · · Score: 1

    This is great, but I find the csh syntax easier to use from the command line (however unsafe it is to use in scripts). Will they add a csh compatability mode to bash?

    1. Re:csh syntax mode? by ichthus · · Score: 5, Funny

      Already there. Just type 'csh' and bash will enter csh-compatibility mode. For scripting, just replace your #!/bin/bash with #!/bin/csh and away you go.

      --
      sig: sauer
    2. Re:csh syntax mode? by Doug+Neal · · Score: 5, Funny

      This is great, but I find the csh syntax easier to use from the command line (however unsafe it is to use in scripts). Will they add a csh compatability mode to bash?

      ln -s /bin/false /bin/csh

      99% of the functionality of csh, without the bugs!

    3. Re:csh syntax mode? by FudRucker · · Score: 3, Interesting

      i think you mean sh, /bin/sh is a symlink to bash in most all Linux systems, calling bash from the sh symlink: Man page ahead::

      If bash is invoked with the name sh, it tries to mimic the startup behavior of his- torical versions of sh as closely as possible, while conforming to the POSIX stan- dard as well. When invoked as an interactive login shell, or a non-interactive shell with the --login option, it first attempts to read and execute commands from /etc/profile and ~/.profile, in that order. The --noprofile option may be used to inhibit this behavior. When invoked as an interactive shell with the name sh, bash looks for the variable ENV, expands its value if it is defined, and uses the expanded value as the name of a file to read and execute. Since a shell invoked as sh does not attempt to read and execute commands from any other startup files, the --rcfile option has no effect. A non-interactive shell invoked with the name sh does not attempt to read any other startup files. When invoked as sh, bash enters posix mode after the startup files are read.

      /bin/csh is usually a symlink to /bin/tcsh in most all Linux systems.

      --
      Politics is Treachery, Religion is Brainwashing
    4. Re:csh syntax mode? by RangerRick98 · · Score: 1, Informative

      WHOOOSH

      --
      "You're older than you've ever been, and now you're even older."
    5. Re:csh syntax mode? by Anonymous Coward · · Score: 0

      Did you hear that? It was the sound of a joke soaring over your head.

    6. Re:csh syntax mode? by Anonymous Coward · · Score: 0

      Going bald?? That what happens when the tiny feet of those little jokes run over your head..

      I'm quite bald too.

    7. Re:csh syntax mode? by Keeper+Of+Keys · · Score: 1

      I'm clearly not enough of a geek. Not only did I not get that the GGP was a joke, but couldn't understand a word of the whoosh. I do actually use Linux as my main dev environment, honest.

      Anyone care to explain why I should care about the difference between different shells?

    8. Re:csh syntax mode? by Random+Destruction · · Score: 2, Informative

      by typing csh, you're loading the c shell and leaving bash. Parent asked for compatibility mode.

      Hilarity ensues.

      As for why you should care which shell is which, you probably don't. You'd only care if you were using more advanced features or scripting. A quick google will show you all your shell can do. It's impressive, really.

      --
      :x
    9. Re:csh syntax mode? by Random+BedHead+Ed · · Score: 4, Funny

      WHOOOSH

      I was following this discussion of bash, sh, csh and tcsh perfectly well, but now I'm lost. What shell are you talking about?

    10. Re:csh syntax mode? by Anonymous Coward · · Score: 0

      i think you mean sh, /bin/sh is a symlink to bash in most all Linux systems, calling bash from the sh symlink: Man page ahead::

                    If bash is invoked with the name sh, it tries to mimic the startup behavior of his-
                    torical versions of sh as closely as possible, while conforming to the POSIX stan-
                    dard as well. When invoked as an interactive login shell, or a non-interactive
                    shell with the --login option, it first attempts to read and execute commands from /etc/profile and ~/.profile, in that order. The --noprofile option may be used to
                    inhibit this behavior. When invoked as an interactive shell with the name sh, bash
                    looks for the variable ENV, expands its value if it is defined, and uses the
                    expanded value as the name of a file to read and execute. Since a shell invoked as
                    sh does not attempt to read and execute commands from any other startup files, the
                    --rcfile option has no effect. A non-interactive shell invoked with the name sh
                    does not attempt to read any other startup files. When invoked as sh, bash enters
                    posix mode after the startup files are read. /bin/csh is usually a symlink to /bin/tcsh in most all Linux systems.

      In Debian and derived, this isn't the case. /bin/sh refers to a custom, dash.

      The reason is performance.

    11. Re:csh syntax mode? by x2A · · Score: 1

      WOOSH is a weplacement shell designed to make BOOST compile faster.

      Woo.

      --
      The revolution will not be televised... but it will have a page on Wikipedia
    12. Re:csh syntax mode? by dkf · · Score: 1

      ln -s /bin/false /bin/csh

      99% of the functionality of csh, without the bugs!

      Try it the other way round for even more fun...

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    13. Re:csh syntax mode? by Keeper+Of+Keys · · Score: 1

      I really only use the unix shell for basic stuff like moving files around, changing permissions, managing apache, and launching apps - but one thing that would improve the quality of my working life no end would be a shell that remembers my python commands, like the Windows command line does. ie if I exit from python, when I next go back into python all my old commands are remembered, just like the unix shell commands are.

      (I spend a lot longer using the python command line; have tried a couple of dedicated python shells but find there are path issues that you don't get with sh> python. As I said, on Windows it just works the way you want.)

    14. Re:csh syntax mode? by ModMeFlamebait · · Score: 1

      Read up on readline (google food: inputrc)

      --
      Pavlov. Does this name ring a bell?
    15. Re:csh syntax mode? by metamatic · · Score: 1

      i think you mean sh, /bin/sh is a symlink to bash in most all Linux systems

      Except Ubuntu, but nobody uses that.

      --
      GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
  3. looks like it still loses history by Froze · · Score: 5, Insightful

    Don't get me wrong, I really like bash, but the treatment of history is abysmal. The default behavior is to lose history due to a race condition when multiple bash sessions that are concurrently open are closed in arbitrary order.

    IMNSHO, the default of any process should be to never lose data.

    --
    -- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
    1. Re:looks like it still loses history by Culture20 · · Score: 1

      So bash should include a bashlog daemon with a sqlite DB? I can't think of a good solution off the top of my head.

    2. Re:looks like it still loses history by lawaetf1 · · Score: 1

      Couldn't agree more. It's quite frustrating to do a history | grep in expectation of reusing some convoluted command only to find that it's not in the list.

      --
      CommentBot 0.7a running with args "-module irritate,disagree -target random"
    3. Re:looks like it still loses history by geekgirlandrea · · Score: 2, Interesting

      Keep the history added in the current session in memory and, when exiting, lock the history file and append? Actually, as far as I know that's what it does; I don't think I've ever seen it actually lose history with multiple concurrent sessions, just add it to the history file in different orders depending on timing. I don't think I've paid that much attention, though.

    4. Re:looks like it still loses history by MostAwesomeDude · · Score: 1

      ^R (Ctrl+R) is reverse-i-search. HTH. ~

      --
      ~ C.
    5. Re:looks like it still loses history by mea37 · · Score: 4, Insightful

      I'll grant I haven't thought this all the way through, but a slightly lighter-weight approach than daemons and databases might look like this:

      Each open session logs history to a uniquely-named file. Then on session close, that file can be appended to the one true history file. (A bit of file locking can maintain atomicity of the append step.)

      When you scroll back into history, you would start with your own session's still-open-and-separate history file -- which is more often than not what I'd expect, but not always what I get today. If you go back beyond the beginning of that, I supposed you'd scroll into the accumulated history of closed sessions.

      This means that one session doesn't "see" the history from a concurrent session while they're both open. That, too, can be addressed, even if it has to wait for a subsequetn release. Either way, it's better than just losing the data IMO.

    6. Re:looks like it still loses history by Hatta · · Score: 1

      Maybe write to ~/.bash-history.PID ? Append it to ~/.bash_history when you close the shell? Even having the history out of order would be better than losing it entirely.

      Of course, this would break for those paranoid folks who link ~/.bash_history to /dev/null

      --
      Give me Classic Slashdot or give me death!
    7. Re:looks like it still loses history by Osso · · Score: 5, Informative

      are you looking for shopt -s histappend ?

    8. Re:looks like it still loses history by init100 · · Score: 1

      Of course, this would break for those paranoid folks who link ~/.bash_history to /dev/null

      One solution is to use a ~/.bash_history.d/$PID file as a temporary storage location. If ~/.bash_history.d exists and is not a directory, don't write any history.

    9. Re:looks like it still loses history by Froze · · Score: 4, Informative

      This almost works. I have tried using an approach like this by building bash scripts and modifying history variables.

      One issue is that sessions that don't terminate cleanly (ssh loss, system reboot, etc.) leave a bunch of dirty history files that would need to reaped at the next start up of a bash.

      --
      -- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
    10. Re:looks like it still loses history by Anonymous Coward · · Score: 0

      It's not abysmal, it's meant to be intuitive, this way bash history record keeping reflects human history record keeping, losing history due to race conditions when multiple civilizations are concurrently in existence and then killed off in arbitrary order.

    11. Re:looks like it still loses history by MikeBabcock · · Score: 5, Interesting

      Log in twice (A) and (B) as the same user, do something in session (A), then log out of (A).

      Now check 'history' as (B), obviously the first session's command isn't there.

      Open another session, (C) and check its history. It is just as you'd expect. Now type a simple command into session (B) and log out of it. What do you think the history is?

      Check history on (C) still logged-in. Log out of (C) and check history on a new login and you'll see that the history matches (C) inherited from (A), no record of (B) happening.

      --
      - Michael T. Babcock (Yes, I blog)
    12. Re:looks like it still loses history by Froze · · Score: 1

      That is what I am currently using, along with some stuff in PROMPT_COMMAND.

      This is an unfriendly hack to fix the default behavior and that is what I am not happy with.

      --
      -- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
    13. Re:looks like it still loses history by Froze · · Score: 2, Funny

      BASH doesn't like it when you anthropomorphize it. ;-)

      --
      -- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
    14. Re:looks like it still loses history by MikeBabcock · · Score: 1

      Log to a PID based history file as well as to an inter-process locked DB history file.

      'history' could then show the commands on this terminal for this session.

      'history -a' could then show all historical commands across all open sessions by the user in proper order.

      PS you can achieve this already by typing 'history -a' whenever you type a series of commands (to commit the new commands to the history immediately) and 'history -n' to read any new lines out of the history file and append them to your current session's stack.

      Its not pretty, but it works.

      --
      - Michael T. Babcock (Yes, I blog)
    15. Re:looks like it still loses history by Anonymous Coward · · Score: 1, Funny

      Wait a minute, you just said BASH doesn't like it when you anthropomorphize it.

      We'll never get out of this one you know...

    16. Re:looks like it still loses history by harry666t · · Score: 1

      Does not work on older items. I currently have got 6773 items in the history, the search usually doesn't work for older than a few dozen most recent. Which is pita.

    17. Re:looks like it still loses history by eosp · · Score: 1

      Whoosh.

    18. Re:looks like it still loses history by Anonymous Coward · · Score: 0

      BASH doesn't like it when you anthropomorphize it. ;-)

      Furry bash?

    19. Re:looks like it still loses history by Lord+Ender · · Score: 1

      As an IT security analyst, I must say I agree with you 1000%. ".bash_history" is a feature with so much potential, but remains a smelly, misleading turd.

      --
      A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
    20. Re:looks like it still loses history by Anonymous Coward · · Score: 1, Funny

      Vroaam.

    21. Re:looks like it still loses history by Anonymous Coward · · Score: 0

      Or you can code something at startup that scans current bash process and checks that there's no history file left without a process (can be easily achieved by agreeing on a naming convention that implies the process ID).

      If there is one, and after a quick check on the format of the file, it can be added to the history. VoilÃ!

    22. Re:looks like it still loses history by Anonymous Coward · · Score: 0

      you're complaining about the default design, not about some bug per se in the code itself

      every shell, upon startup, reads the entire history file. then while running, the shell updates its own in-memory copy. upon exit, the entire in-memory history is written to the history file.

      if you dont like the default behavior, RTFM. as Osso points out, there's this crazy thing called "histappend".

    23. Re:looks like it still loses history by vadim_t · · Score: 1

      For security, how can you trust user controlled files?

      It's easy to mess with the history file. I could "ln -sf /dev/null .bashrc". I could start any text editor, like vi, open the file from inside it, and remove incriminating lines. I could strategically use the history bug and make sure that the lines I want are overwritten.

      A more interesting option is uploading a program that contains a function that messes with the history file, or even its own shell.

      The only way you can trust logged commands if the logging was performed outside the user's control, and the user had no way to evade it.

    24. Re:looks like it still loses history by Anonymous Coward · · Score: 2, Informative

      That's only part of the solution. Yes, that will retain all recent commands but not in the order in which they were entered (instead, commands will be stored in the order in which the shells were closed).

      In order for history to be kept in chronological order, you need to
      $ set PROMPT_COMMAND='history -a'
      which I think is an ugly hack, but it ensures that the history file is appended (or rewritten, without histappend) each time the command prompt returns.

    25. Re:looks like it still loses history by wsanders · · Score: 4, Insightful

      Bah. History files are a horrible security problem. History belongs in memory. I can count on about ten hands the number of times I have found passwords and various other sensitive information in them.

      First line in my .bashrc files: unset HISTFILE

      --
      Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
    26. Re:looks like it still loses history by RichardJenkins · · Score: 1

      Ye gads it's true! That explains everything!

    27. Re:looks like it still loses history by threephaseboy · · Score: 4, Informative

      I did exactly as you said, and at the new login I had the commands from A,B,C (in that order) in history.
      Here's what it looks like:

        996  echo AAA # A
        997  history|tail # checking history on B
        998  echo BBB # B
        999  history|tail # checking history on C
      1000  history|tail # checking history on C, again
      1001  history |tail # new login

      This is:
      GNU bash, version 3.2.33(1)-release (x86_64-redhat-linux-gnu)

      --
      .
    28. Re:looks like it still loses history by RichardJenkins · · Score: 1

      richard@laptop:~$ cat ~/.bash_history | wc -l

      50659

      I win! I should do an analysis on how many keystrokes I'd have saved myself over the last few years with some strategic aliases.

      Seriously though, my ctrl-R history seems to go back a lot further than a few dozen. Maybe it's a setting you can change?

    29. Re:looks like it still loses history by techno-vampire · · Score: 2, Interesting
      Don't get me wrong, I really like bash, but the treatment of history is abysmal.

      I guess that I must be weird or something. I don't expect bash to retain history from one invocation to the next, and I'm always surprised when it happens.

      --
      Good, inexpensive web hosting
    30. Re:looks like it still loses history by Mad+Merlin · · Score: 1

      I think he means he doesn't find ^R useful past the most recent dozen or so commands, which is pretty reasonable until you realize that you can hit ^R again (and again, and again...) to go to the next (previous) match.

    31. Re:looks like it still loses history by vipw · · Score: 1

      .bash_history isn't a security audit. It's for the user's convenience and has nothing to do with security.

      An ACL system can be useful for security audit, and they aren't controlled by the user.

    32. Re:looks like it still loses history by sketerpot · · Score: 1

      Don't worry. We can liken Bash to a largemouth bass, and say that it doesn't like to be anthropomorphized (because it's a fish, not a human) and we'll have ended the loop. If you learn Haskell, you'll get this good at recursion.

    33. Re:looks like it still loses history by vadim_t · · Score: 1

      Precisely what I'm saying. The grandparent is a "security analyst" complaining about the .bash_history file being incomplete. I'm asking, even if it was complete, it's ultimately under the user's control, so how could you trust its contents, given so many ways to mess with it?

    34. Re:looks like it still loses history by Anonymous Coward · · Score: 0

      An even better aproach would be to install zsh :-)

    35. Re:looks like it still loses history by Anonymous Coward · · Score: 0

      This means that one session doesn't "see" the history from a concurrent session while they're both open.

      Which is greatly useful. I run multiple concurrent sessions for different tasks, and expect the history on each to not interfere with the others.

      Maybe there should be a setting to glob history over sessions, but independent histories as it is now are a better when/if running independent tasks as I often do.

    36. Re:looks like it still loses history by Anonymous Coward · · Score: 0

      And installing ksh would be even better than that. ;)

    37. Re:looks like it still loses history by yanos · · Score: 1

      Perhaps you could write yet another script called at startup that could find those dirty files and append their content into the main history file. I agree that this setup could be getting a little too much for what it does though, bash ought to have that kind of functionality by default.

    38. Re:looks like it still loses history by 10101001+10101001 · · Score: 1

      One issue is that sessions that don't terminate cleanly (ssh loss, system reboot, etc.) leave a bunch of dirty history files that would need to reaped at the next start up of a bash.

      1. Open a temporary history file to obtain a file descriptor
      2. Delete the temporary history file
      3. Use the existing file descriptor to read/write to the "deleted" file
      4. If the session terminates uncleanly, the OS, fsck, or journal playback will clear the file
      5. On clean session termination, read the "deleted" file and dump it to the history, closing the file descriptor and actually deleting the file

      AFAIK, this will even work in Windows 2000/XP/Vista, although you'll have to use some special flags to obtain the effect.

      --
      Eurohacker European paranoia, gun rights, and h
    39. Re:looks like it still loses history by Lord+Ender · · Score: 1

      Forensics. Real life digital forensics is not the ideal scenario you invent in your head. In real life, attackers break in, take what they want, and leave/spread. I've never seen one that spent any time bothering with rootkits or covering his tracks.

      --
      A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
    40. Re:looks like it still loses history by Anonymous Coward · · Score: 1, Insightful

      Well you *wouldn't* see an attacker who spent any time bothering with rootkits or covering his tracks if you're only looking at .bash_history, now would you? :)

    41. Re:looks like it still loses history by Junior+J.+Junior+III · · Score: 1

      are you looking for shopt -s histappend ?

      I can't be the only who read that as

      shopt -shit happened ...can I?

      --
      You see? You see? Your stupid minds! Stupid! Stupid!
    42. Re:looks like it still loses history by Junior+J.+Junior+III · · Score: 1

      are you looking for shopt -s histappend ?

      I can't be the only one who read that as

      shopt -shit happened

      ...can I?

      --
      You see? You see? Your stupid minds! Stupid! Stupid!
    43. Re:looks like it still loses history by tiananmen+tank+man · · Score: 1

      GP was talking about the default behaviour. You can use shopt (shell option) command to change the histappend option to get your desired effect.

    44. Re:looks like it still loses history by umeboshi · · Score: 1

      I use HISTCONTROL=ignoredups:ignorespace for typing in sensitive commands. The important part is "ignorespace", although I combine that with ignoredups. When this is set, any command that starts with a space will not be written to history (both memory and ~/.bash_history).

    45. Re:looks like it still loses history by profplump · · Score: 1

      Which is fine while the session is open, and I don't think anyone would want to change that.

      But when you close both sessions, it would be nice if both of them made it into the history file -- otherwise when you come back tomorrow and start a third session you can only use your history for one of the two tasks (and you have to try pretty hard to even get to choose which of the two you get).

    46. Re:looks like it still loses history by marafa · · Score: 0

      how about this instead?

        shopt -s histappend

      --
      _ In Egypt Networks: Network Solutions with a Twist
    47. Re:looks like it still loses history by chthon · · Score: 1

      You have to enable histappend in your .bashrc :

      shopt -s histappend

    48. Re:looks like it still loses history by Waccoon · · Score: 1

      When will it finally be commonplace to encrypt all histories and caches? More importantly, when will applications have private temp folders inaccessible to other processes on the same login, so they can keep their keys secure?

    49. Re:looks like it still loses history by xaxa · · Score: 1

      I just remember unique bits of useful commands I write. Three months after I did something, I end up typing ^R $e to bring up a massive for loop, which I remembered used e as the variable.

    50. Re:looks like it still loses history by x2A · · Score: 3, Informative

      or just add to your bashrc/profile scripts:
      shopt -s histappend

      --
      The revolution will not be televised... but it will have a page on Wikipedia
    51. Re:looks like it still loses history by sbryant · · Score: 1

      Mine doesn't do that. Mind you, I have a separate history file per tty:

      export HISTFILE=$HOME/.history.${tty##*/}

      -- Steve

    52. Re:looks like it still loses history by x2A · · Score: 2, Informative

      I've said it in another post, but just to be helpful:
      shopt -s histappend
      add to your bashrc/profile scripts. Should do the trick for ya.

      --
      The revolution will not be televised... but it will have a page on Wikipedia
    53. Re:looks like it still loses history by a1291762 · · Score: 1

      Here's how you avoid losing history. I know... you said "the default should be" but it is at least possible. I'm sure most people don't actually use multiple shells at the same time anyway ;)

      # Don't clobber .bash_history
      shopt -s histappend
      HISTFILE=$HOME/.bash_history
      # This should be enough to last for years
      HISTFILESIZE=1000000000
      HISTSIZE=1000000
      #HISTCONTROL=ignorespace # start a command with a space and it doesn't go into t
      HISTCONTROL=ignoredups # ignore duplicates
      #HISTCONTROL=ignoreboth # both of the above
      precmd()
      {
              history -a # export history
      }
      PROMPT_COMMAND=precmd

      I have precmd as a function because my precmd actually does more than just exporting history.

      What this does is to append every command you run in every shell to ~/.bash_history. If you run history -n you import watever is not in your current shell's history from .bash_history. You can even put history -n in your precmd but that can give somewhat unexpected results when you are using multiple shells at once.

    54. Re:looks like it still loses history by drinkypoo · · Score: 1

      are you looking for shopt -s histappend ?

      They were looking for that to be the default in bash. Next time read and understand before replying. Congratulations on your undeserved upmods though.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    55. Re:looks like it still loses history by RichiH · · Score: 1

      Bah. Knives are a horrible security problem. Food should come pre-cut. I can count on about ten hands the number of times I have heard of people cutting their finger.

      If people are that stupid, they will find a way to shoot themselves into their foot. If you _need_ to provide a password on CLI (i.e. almost never), you can disable history or, using zsh, either edit the history stack before it's written to file or

          setopt histignorespace

      which will enable you to

          ` secretstuff`

      which is then not written to disk.

    56. Re:looks like it still loses history by Anonymous Coward · · Score: 0

      chattr +a .bash_history

      This method will solve the problem, with the drawback that you need to manually truncate/archive the history file (using "chattr -a" first) when it approaches $HISTFILESIZE. After the chattr, even root can't truncate the file.

    57. Re:looks like it still loses history by BESTouff · · Score: 1

      Easy solution: remove the file just after creating it. That's an old unix trick, where the removed file in fact still exists for the processes that had it opened, until they close it (by close() or death).

    58. Re:looks like it still loses history by k8to · · Score: 1

      histappend is part of making bash act reasonably.

      In the words of Aaron Crane:

          # Append to the history file on shell exit, don't overwrite (so multiple
          # exiting shells don't race to scribble over your saved history)
          shopt -s histappend

          # Keep lots of history around
          export HISTSIZE=1000000 HISTFILESIZE=1000000

          # Store history in a different file, so it won't get overwritten if you
          # don't have these settings
          export HISTFILE=~/.bash_history_safe

          # Write unsaved history immediately before emitting each prompt
          export PROMPT_COMMAND='history -a'

      --
      -josh
    59. Re:looks like it still loses history by jantman · · Score: 1

      1) passwords shouldn't appear in clear text on the command line. It's not BASH's problem... and program that doesn't have an argument to prompt for password is broken. 2) Realistically, while we should all work next to stenographers who take down every note that we mumble, we don't, I don't remember how many times I've asked myself "how the **** did I get that to work yesterday?" and found the answer in .bash_history.

    60. Re:looks like it still loses history by Viol8 · · Score: 1

      "when will applications have private temp folders "

      Who cares? Are you worried one of your own programs might sabotage another?? And anyone or thing with root access will be able to read it anyway.

    61. Re:looks like it still loses history by anonymous+donor · · Score: 1

      x86_64-redhat-linux-gnu

      The problem is not with bash's default configuration but with configuration shipped with various distributions. Grandparent uses probably Ubuntu, and I can confirm that it's broken there just like he describes.

      I think they inherited it from Debian, but (flame ahead) wouldn't be suprised if it was their own invention, just as broken flash, sound, or networking.

      --
      fortune favors the lucky
    62. Re:looks like it still loses history by vernonB · · Score: 1

      oh please. it's *got* to remember shit from one invocation to the next. the older you get, the more you need to grep your $HISTFILE

    63. Re:looks like it still loses history by Lord+Ender · · Score: 1

      No, but you would see it in off-system logs and network logs. Boy that anonymous coward is a clever guy, though! Hur hur!

      --
      A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
    64. Re:looks like it still loses history by bdrewery · · Score: 1

      Don't get me wrong, I really like bash, but the treatment of history is abysmal. The default behavior is to lose history due to a race condition when multiple bash sessions that are concurrently open are closed in arbitrary order.

      IMNSHO, the default of any process should be to never lose data.

      export PROMPT_COMMAND="history -a" This will append every new line to the file immediately.

    65. Re:looks like it still loses history by InverseParadox · · Score: 1

      Of course, there are also times when you don't want to do that - such as when you typed an important password in cleartext in such a way that it would enter the command history, which I've done more than once. The ability to trivially and conveniently wipe it out of the long-term history, done in this case by ensuring that the session which had the password isn't the one whose history gets preserved, is not something I'd want to lose either.

      --
      -- The Wanderer
    66. Re:looks like it still loses history by techno-vampire · · Score: 1

      I'm 59, and haven't needed it yet. Either you need to get back on your meds, or get them changed, ASAP.

      --
      Good, inexpensive web hosting
    67. Re:looks like it still loses history by Waccoon · · Score: 1

      Are you worried one of your own programs might sabotage another??

      Yes, because they are not my programs.

      I realize this is out of place in an article about BASH, but it is a very real problem. With all these plugins, extensions, and VMs these days, security is almost exclusively an application-level problem. The OS will cover its own butt, but can't keep your Home folder safe from anything running on your account. FOSS or not, thinking that all software running under the same account will get along perfectly is naive.

      And anyone or thing with root access will be able to read it anyway.

      If you grant such access, of course. Unless you're stuck in the Windows world, there's not much out there that really needs root access. I've used dozens of OSes over the years, so when somebody brings up the issue of security, I tend to talk about more than just UNIX/GNU or shells. I'm sorry if that wasn't clear.

    68. Re:looks like it still loses history by Viol8 · · Score: 1

      "all software running under the same account will get along perfectly is naive."

      Sorry , why wouldn't it? Perhaps in Windows apps stomp all over each other but I've never come across that problem in unix or linux. If you configure them to use their own specific directories whats the problem?

      "If you grant such access, of course"

      Err, root can read and do what it likes. As a normal user you don't get a choice in the matter. If someone or thing with root access wants to go through your home directory they will and theres bugger all you can do about it. The only exception to this was in old HP-UX systems were chmod had a -h option to hide files , but even then root could view them if he knew the name.

  4. patience by Anonymous Coward · · Score: 5, Funny

    i'll wait for 4.2

    1. Re:patience by Anonymous Coward · · Score: 3, Funny

      I see what you did there with the clever alluding to another...nevermind...

    2. Re:patience by Anonymous Coward · · Score: 0

      wut?

      Posting AC to preserve my geek card.

    3. Re:patience by jetsci · · Score: 2, Informative

      Give me a K..DE!

      --
      Bored at work? Play Game!
    4. Re:patience by Anonymous Coward · · Score: 0

      I believe this is a reference to the complaints about KDE4 and KDE4.2, which appears to have alleviated some of these problems.

    5. Re:patience by Anonymous Coward · · Score: 0

      KDE 4.0 sucked. The idea is that because this is also a 4.0 it will also suck.

      Sounds like you are probably more farmilar with Windows, so the analogy would be if this happened to be called BASH Vista.

      Of course, BASH Vista would probably be pretty popular with the Slashdot crowd.

    6. Re:patience by Tarlus · · Score: 4, Funny

      Give me a K..DE!

      You tried to say 'KDE' but there was a lag before it completed... Just like true KDE4!

      *Runs away*

      --
      /* No Comment */
    7. Re:patience by TeXMaster · · Score: 1

      The interesting thing about version 4 is that it seems to be a generally sucky version. Anybody remember DOS 4?

      --
      "I'm never quite so stupid as when I'm being smart" (Linus van Pelt)
    8. Re:patience by RichardJenkins · · Score: 1

      Or Superman 4?

    9. Re:patience by TeXMaster · · Score: 2, Funny
      Or Star Wars Episode I?

      Uh ... wait a sec ...

      --
      "I'm never quite so stupid as when I'm being smart" (Linus van Pelt)
    10. Re:patience by Anonymous Coward · · Score: 0

      Or Police Academy 4?

    11. Re:patience by Anonymous Coward · · Score: 0

      Damn. Thought it must of been a Hitchhiker's Guide reference.

    12. Re:patience by Barromind · · Score: 1

      No, but I remember Winamp 4...

  5. GNU Bash, version 4.0 by Anonymous Coward · · Score: 1, Informative

    This is GNU Bash, version 4.0. Bash is the GNU Project's Bourne
    Again SHell, a complete implementation of the POSIX.2 shell spec,
    but also with interactive command line editing, job control on
    architectures that support it, csh-like features such as history
    substitution and brace expansion, and a slew of other features.
    For more information on the features of Bash that are new to this
    type of shell, see the file `doc/bashref.texi'. There is also a
    large Unix-style man page. The man page is the definitive description
    of the shell's features.

    See the file POSIX for a discussion of how the Bash defaults differ
    from the POSIX.2 spec and a description of the Bash `posix mode'.

    There are some user-visible incompatibilities between this version
    of Bash and previous widely-distributed versions, bash-2.05b and
    bash-3.2. For details, see the file COMPAT. The NEWS file tersely
    lists features that are new in this release.

    Bash is free software, distributed under the terms of the [GNU] General
    Public License as published by the Free Software Foundation,
    version 3 of the License (or any later version). For more information,
    see the file COPYING.

    A number of frequently-asked questions are answered in the file
    `doc/FAQ'.

    To compile Bash, try typing `./configure', then `make'. Bash
    auto-configures the build process, so no further intervention
    should be necessary. Bash builds with `gcc' by default if it is
    available. If you want to use `cc' instead, type

            CC=cc ./configure

    if you are using a Bourne-style shell. If you are not, the following
    may work:

            env CC=cc ./configure

    Read the file INSTALL in this directory for more information about how
    to customize and control the build process. The file NOTES contains
    platform-specific installation and configuration information.

    If you are a csh user and wish to convert your csh aliases to Bash
    aliases, you may wish to use the script `examples/misc/alias-conv.sh'
    as a starting point. The script `examples/misc/cshtobash' is a
    more ambitious script that attempts to do a more complete job.

    Reporting Bugs
    ==============

    Bug reports for bash should be sent to:

            bug-bash@gnu.org

    using the `bashbug' program that is built and installed at the same
    time as bash.

    The discussion list `bug-bash@gnu.org' often contains information
    about new ports of Bash, or discussions of new features or behavior
    changes that people would like. This mailing list is also available
    as a usenet newsgroup: gnu.bash.bug.

    When you send a bug report, please use the `bashbug' program that is
    built at the same time as bash. If bash fails to build, try building
    bashbug directly with `make bashbug'. If you cannot build `bashbug',
    please send mail to bug-bash@gnu.org with the following information:

            * the version number and release status of Bash (e.g., 2.05a-release)
            * the machine and OS that it is running on (you may run
                `bashversion -l' from the bash build directory for this information)
            * a list of the compilation flags or the contents of `config.h', if
                appropriate
            * a description of the bug
            * a recipe for recreating the bug reliably
            * a fix for the bug if you have one!

    The `bashbug' program includes much of this automatically.

    If you would like to contact the Bash maintainers directly, send mail
    to bash-maintainers@gnu.org.

    While the Bash maintainers do not promise to fix all bugs, we would
    like this shell to be the best that we can make it.

    Enjoy!

    1. Re:GNU Bash, version 4.0 by Anonymous Coward · · Score: 0

      Why is this modded down?

      This is GNU Bash, version 4.0. Bash is the GNU Project's Bourne Again SHell, a complete implementation of the POSIX.2 shell spec, but also with interactive command line editing, job control on architectures that support it, csh-like features such as history substitution and brace expansion, and a slew of other features. For more information on the features of Bash that are new to this type of shell, see the file `doc/bashref.texi'. There is also a large Unix-style man page. The man page is the definitive description of the shell's features.

      See the file POSIX for a discussion of how the Bash defaults differ from the POSIX.2 spec and a description of the Bash `posix mode'.

      There are some user-visible incompatibilities between this version of Bash and previous widely-distributed versions, bash-2.05b and bash-3.2. For details, see the file COMPAT. The NEWS file tersely lists features that are new in this release.

      Bash is free software, distributed under the terms of the [GNU] General Public License as published by the Free Software Foundation, version 3 of the License (or any later version). For more information, see the file COPYING.

      A number of frequently-asked questions are answered in the file `doc/FAQ'.

      To compile Bash, try typing `./configure', then `make'. Bash auto-configures the build process, so no further intervention should be necessary. Bash builds with `gcc' by default if it is available. If you want to use `cc' instead, type

      CC=cc ./configure

      if you are using a Bourne-style shell. If you are not, the following may work:

      env CC=cc ./configure

      Read the file INSTALL in this directory for more information about how to customize and control the build process. The file NOTES contains platform-specific installation and configuration information.

      If you are a csh user and wish to convert your csh aliases to Bash aliases, you may wish to use the script `examples/misc/alias-conv.sh' as a starting point. The script `examples/misc/cshtobash' is a more ambitious script that attempts to do a more complete job.

      Reporting Bugs ==============

      Bug reports for bash should be sent to:

      bug-bash@gnu.org

      using the `bashbug' program that is built and installed at the same time as bash.

      The discussion list `bug-bash@gnu.org' often contains information about new ports of Bash, or discussions of new features or behavior changes that people would like. This mailing list is also available as a usenet newsgroup: gnu.bash.bug.

      When you send a bug report, please use the `bashbug' program that is built at the same time as bash. If bash fails to build, try building bashbug directly with `make bashbug'. If you cannot build `bashbug', please send mail to bug-bash@gnu.org with the following information:

      * the version number and release status of Bash (e.g., 2.05a-release) * the machine and OS that it is running on (you may run `bashversion -l' from the bash build directory for this information) * a list of the compilation flags or the contents of `config.h', if appropriate * a description of the bug * a recipe for recreating the bug reliably * a fix for the bug if you have one!

      The `bashbug' program includes much of this automatically.

      If you would like to contact the Bash maintainers directly, send mail to bash-maintainers@gnu.org.

      While the Bash maintainers do not promise to fix all bugs, we would like this shell to be the best that we can make it.

      Enjoy!

  6. Circular what? by palegray.net · · Score: 2, Funny

    So, I'm gonna grab the source to BASH and compile it using GCC under BASH? My brain hurts :).

    1. Re:Circular what? by Locklin · · Score: 4, Funny

      stay away from kernel.org then.

      --
      "Knowledge is the only instrument of production that is not subject to diminishing returns" -Journal of Political Econom
    2. Re:Circular what? by slim · · Score: 5, Insightful

      What do you think was used to compile GCC?

    3. Re:Circular what? by Paralizer · · Score: 2, Informative

      It's commonly referred to as bootstrapping. For instance, you might bootstrap your compiler by using an older version to compile the newer version of that compiler.

    4. Re:Circular what? by Hatta · · Score: 5, Funny

      Sup dawg, I heard you liked compiling, so I put a compiler in your compiler so you can compile while you compile.

      --
      Give me Classic Slashdot or give me death!
    5. Re:Circular what? by Paralizer · · Score: 1

      Does it involve any type of yo-yo's?

    6. Re:Circular what? by fulldecent · · Score: 5, Funny

      Your mom?

      --

      -- I was raised on the command line, bitch

    7. Re:Circular what? by line-bundle · · Score: 1

      small brain eh?

    8. Re:Circular what? by SatiricComet · · Score: 5, Funny

      Visual Studio 2008?

    9. Re:Circular what? by glwtta · · Score: 2, Funny

      Bash?

      --
      sic transit gloria mundi
    10. Re:Circular what? by skeeto · · Score: 1

      What do you think was used to compile GCC?

      Do you think that's air you're breathing now?

    11. Re:Circular what? by LaminatorX · · Score: 1

      An egg, no wait a chicken.

      I hate this game.

    12. Re:Circular what? by Ant+P. · · Score: 4, Funny

      EGCS, duh.

    13. Re:Circular what? by Anonymous Coward · · Score: 0

      What do you think was used to compile GCC?

      BASH?

    14. Re:Circular what? by Anonymous Coward · · Score: 0

      Ahh but does it run emacs?

    15. Re:Circular what? by renegadesx · · Score: 1

      Then compile it with something else, that way your comiling BASH using on a Linux kernel GCC running under pdksh, tcsh or zsh!

      Problem solved, just dont attempt to think about compiling GCC or the kernel, your head may explode!

      --
      Make SELinux enforcing again!
    16. Re:Circular what? by palegray.net · · Score: 1

      What's that whooshing noise?

    17. Re:Circular what? by palegray.net · · Score: 1

      Only singular yos, and only in Baltimore.

    18. Re:Circular what? by Anonymous Coward · · Score: 0

      Sup dawg, I heard you liked compiling, so I put a compiler in your compiler so you can compile while you compile.

      Ah, I see you use Gentoo as well.

    19. Re:Circular what? by brackishboy · · Score: 1

      The egg?

    20. Re:Circular what? by Anonymous Coward · · Score: 0

      Pimp my GCC? Slashdot has reached a new low.

    21. Re:Circular what? by Anonymous Coward · · Score: 0

      Emacs?

    22. Re:Circular what? by Anonymous Coward · · Score: 0

      until a couple years ago, GCC's "make bootstrap" could start out with any K&R compiler, then build GCC, then use that GCC to build itself, then do it again for good measure and to compare both GCC's gave the same output.

      GCC sources tend to expose some nasty compiler bugs, both in system compilers and in itself.

      A while ago the K&R restriction was relaxed. But you can still write your own K&R compiler, in assembly if you want (not that hard as it doens't have to optimize or anything), then bootstrap a 3.x GCC and use that to bootstrap a 4.0

      Back in 2000 or so it took a few hours to bootstrap GCC though. I don't recommend it.

    23. Re:Circular what? by g2devi · · Score: 1

      Emacs?

    24. Re:Circular what? by Anonymous Coward · · Score: 0

      sorry i left the faucet running

    25. Re:Circular what? by Anonymous Coward · · Score: 0

      damn dude never heard the term boot-strapping?

    26. Re:Circular what? by Anonymous Coward · · Score: 0

      My brain hurts :).

      You could just use a computer to run the compiler, you know...

    27. Re:Circular what? by lordtoran · · Score: 1

      COCOL?

      --
      Want to hear the voice of GOD? cat /boot/vmlinuz > /dev/dsp
  7. New features be damned by Anonymous Coward · · Score: 0

    Nobody will really care about the new features so long as "man woman" still does that vagina-less woman joke.

    1. Re:New features be damned by Anonymous Coward · · Score: 0

      $ man woman
      No manual entry for woman

      And that's the way I like it. I hate it when my girl tries to fist me.

    2. Re:New features be damned by larry+bagina · · Score: 1

      but you don't mind when cowboy neal tries?

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

  8. Bugs by microbee · · Score: 2, Funny

    The new major release fixes several remaining bugs in the 3.x releases

    That's great, but they forgot to mention how many new bugs were introduced.

    1. Re:Bugs by 228e2 · · Score: 1

      trust me, they didnt "forget"

      --
      Since when does being a Socialist mean 'someone who has a different opinion than me'?
    2. Re:Bugs by machine321 · · Score: 1

      That's great, but they forgot to mention how many new bugs were introduced.

      All of them.

    3. Re:Bugs by iYk6 · · Score: 1

      The new major release fixes several remaining bugs in the 3.x releases

      That's great, but they forgot to mention how many new bugs were introduced.

      It's a .0 release. They don't know how many new bugs were introduced yet.

    4. Re:Bugs by Anonymous Coward · · Score: 0

      The reason your scripts no longer work is because of bugs in the *previous* release, which have now been fixed.

      Sometimes I hate working with free software. The joys of finding CVS repositories and trying to find which source files would have the relevant log messages between releases...

    5. Re:Bugs by baka_toroi · · Score: 1

      Thanks, Sheldon Cooper.

  9. Re:Linux by Anonymous Coward · · Score: 5, Funny

    Still gay.

    Don't bash it dude.

  10. case-modifying word expansions by Fallingcow · · Score: 1

    case-modifying word expansions

    Oh, good.

    I'm sure someone likes case-sensitive filenames, but they annoy me way more often than I find them useful. Maybe this will reduce or eliminate one of my biggest problems with them.

    1. Re:case-modifying word expansions by Kozar_The_Malignant · · Score: 1

      case-modifying word expansions

      Personally, I think that when the OS shell starts doing its own case-mods we are just a touch too close to a self aware, self-replicating machine. And all with just a work-expansion routine? Stop this madness before the damn things try to take over! Oh, wait..... Never mind.

      --
      Some mornings it's hardly worth chewing through the restraints to get out of bed.
    2. Re:case-modifying word expansions by RichiH · · Score: 1

      You might just have used zsh instead. It's nice that Bash has caught up in some ways (ass array, **, etc) though :p

    3. Re:case-modifying word expansions by bjourne · · Score: 1

      Actually, case-sensitive filenames are very useful. Otherwise you wouldn't be able to represent filenames with upper and lowercase letters. Case-sensitive *matching* on the other hand, is just stupid.

  11. My Dr. Seuss observation... by drakaan · · Score: 4, Funny

    "...The most notable new features are associative arrays..."

    So now I can make a BASH hash, sweet!

    --
    "Murphy was an optimist" - O'Toole's commentary on Murphy's Law
    1. Re:My Dr. Seuss observation... by Anonymous Coward · · Score: 0

      while wearing a sexy sash, how neat!

    2. Re:My Dr. Seuss observation... by Anonymous Coward · · Score: 0

      some words here... LASH DASH... other words... TWEET

      YAY! I CAN RHYME TOO!

    3. Re:My Dr. Seuss observation... by garyebickford · · Score: 2, Funny

      I've been making a hash of BASH for years! Just ask the folks who review my code!

      --
      It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
    4. Re:My Dr. Seuss observation... by Ken_g6 · · Score: 1

      "...The most notable new features are associative arrays..."

      So now I can make a BASH hash, sweet!

      You should try some of the alpha versions. I'm sure you could get a BASH hash crash!

      --
      (T>t && O(n)--) == sqrt(666)
    5. Re:My Dr. Seuss observation... by Hillgiant · · Score: 1

      But his manager still won't like it, he will claim the BASH hash crash is trash.

      --
      -
    6. Re:My Dr. Seuss observation... by Anonymous Coward · · Score: 0

      A new bash? Aight, I put on my robe and wizard hat.

    7. Re:My Dr. Seuss observation... by windsurfer619 · · Score: 1

      By getting a list of other shells, you could create a dash of Bash hash mash

    8. Re:My Dr. Seuss observation... by Anonymous Coward · · Score: 0

      What the f*ck, I told you not to message me again.

    9. Re:My Dr. Seuss observation... by drakaan · · Score: 1

      You owe me a new keyboard...

      --
      "Murphy was an optimist" - O'Toole's commentary on Murphy's Law
    10. Re:My Dr. Seuss observation... by Anonymous Coward · · Score: 0

      a hash bang slash bin slash bash hash?

  12. Zsh has had these features for years by urdak · · Score: 5, Informative

    I've been using Zsh (the Z shell) for years, because it had better completion, and a richer bourne-shell and ksh-based programming language including also associative arrays and the co-process.
    So it would appear that bash finally caught up. But zsh has continued to improve. I'll be sticking with zsh for now, until I see that bash really caught up.

    1. Re:Zsh has had these features for years by Curate · · Score: 3, Funny

      Please, no more GNU bashing.

    2. Re:Zsh has had these features for years by Hatta · · Score: 5, Funny

      Excellent post. I look forward to the ensuing flame war.

      --
      Give me Classic Slashdot or give me death!
    3. Re:Zsh has had these features for years by TheRaven64 · · Score: 1

      I oscillate between the two, sticking with one until it irritates me enough and then switching to the other. While I love zsh's autocompetion of remote scp filenames, I can't stand the way it does this synchronously, causing the terminal to freeze if I made a typo in the host name. I also found the vi mode in zsh to be inferior to the equivalent in bash last time I tried it, but maybe it's improved since then.

      --
      I am TheRaven on Soylent News
    4. Re:Zsh has had these features for years by Just+Some+Guy · · Score: 4, Funny

      I also found the vi mode in zsh to be inferior to the equivalent in bash last time I tried it, but maybe it's improved since then.

      That's because Emacs's bindings are far more logical than Vi's, especially when running on FreeBSD instead of Linux. Oh, and indent with spaces.

      Did I miss anything?

      --
      Dewey, what part of this looks like authorities should be involved?
    5. Re:Zsh has had these features for years by Anonymous Coward · · Score: 0

      You might want to check out FISH: it has some really cool features that I wish ZSH would implement. The main one is syntax highlighting and indentation.

    6. Re:Zsh has had these features for years by Anonymous Coward · · Score: 0

      So it would appear that bash finally caught up. But zsh has continued to improve. I'll be sticking with zsh for now, until I see that bash really caught up.

      Is that intended to be a serious statement?

    7. Re:Zsh has had these features for years by Fweeky · · Score: 2, Interesting

      -# make missing
      devel/doxygen
      devel/tmake
      print/dvipsk-tetex
      print/teTeX
      devel/qt4-corelib
      x11-toolkits/qt4-gui
      textproc/qt4-xml
      devel/qmake4
      devel/qt4-moc
      devel/qt4-rcc
      print/tex-texmflocal
      print/teTeX-texmf
      print/teTeX-base
      www/libwww
      print/cm-super
      print/xdvik
      devel/qt4-uic
      devel/oniguruma
      print/cmpsfont
      print/amspsfnt
      x11-toolkits/open-motif

      A shell wants to suck in half of qt? :/

    8. Re:Zsh has had these features for years by Anonymous Coward · · Score: 1, Insightful

      a richer bourne-shell and ksh-based programming language

      Interesting. Whenever I needed to write programs beyond what POSIX sh could handle, I just eschewed shell entirely and went up to Perl/Python/Ruby. Still even more powerful, and installed on far more boxes.

      bash, ksh, zsh, etc. are still better for interactive use, but salivating over their programming features is really missing the forest for the trees, in my opinion.

    9. Re:Zsh has had these features for years by Anonymous Coward · · Score: 0

      You forgot to start a GNOME vs. KDE flamewar and the real programming language flamewar, everything else was just right.

    10. Re:Zsh has had these features for years by 0xABADC0DA · · Score: 4, Interesting

      The reasons I use zsh and not bash:

      1) ... some pipeline | read variable

      In zsh you can use $variable to get the value. In base you have to do variable=$(... pipeline | { read variable; echo $variable; } ), and this is annoying and complicated when doing anything more than reading just one variable.

      2) tab completion doesn't have a cycle mode (like DOS's completion)

      abc-1.2.3
      abc-1.2.4
      abc-2.0.1
      abcdef

      In bash you have to do "a, tab, -, tab, 1, tab, 3" to get the first one. That means you have to know all the filenames so that you know what letter to press to get the next 'section' of the filename you want (you can double-tab to get a menu, but it's annoying). In zsh you can configure it to cycle, so to get the first one you type "a, tab" or the second one "a, tab, tab".

      3) rm -f -- $FILE

      In zsh, this does what you want, removing the files. In bash you have to say "$FILE" because if it has a space it is treated as two parameters, and also wildcard expanded. It's annoying to have 1/3 of the script be " characters.

      4) bash history has problem with multiple shells. It only writes the commands when the shell exists, so if it exits unexpectedly your history is lost. And if you open up another terminal you can't ctrl-r for recent commands in another window.

      5) zsh's line editor is better when editing multi-line commands and just generally readline is a pos. After having to use readline in a C program I have a huge bias against anything using it. It sounds like they improved it slightly by being able to remember the prompt text... before to erase the prompt and reshow it (in order to print async text) you had to remember the prompt index, delete the prompt text, save the prompt, clear the message, your code here, then restore the prompt, undo the delete of the text, restore the prompt index (by setting a global variable), then redisplay the prompt, then set the prompt string. Oh, and each one of these functions is just poorly documented enough that you feel like it might possibly tell you what you need to know, then you find out the time you spent figuring out how to navigate an 'info' file (again) was completely wasted.

    11. Re:Zsh has had these features for years by Anonymous Coward · · Score: 0

      A shell wants to suck in half of qt? :/

      That's probably because of doxygen and its qt frontend. I'm sure ports has a way to disable it.

    12. Re:Zsh has had these features for years by Anonymous Coward · · Score: 0

      Too bad zsh hasn't caught up to ksh yet.

    13. Re:Zsh has had these features for years by Anonymous Coward · · Score: 0

      I also found the vi mode in zsh to be inferior to the equivalent in bash last time I tried it, but maybe it's improved since then.

      That's because Emacs's bindings are far more logical than Vi's, especially when running on FreeBSD instead of Linux. Oh, and indent with spaces.

      Did I miss anything?

      GNOME FOR THE WIN!!!

      That should just about cover it.

    14. Re:Zsh has had these features for years by Opyros · · Score: 1

      How about "The Balrog has wings, not just shadows in the shape of wings!"

    15. Re:Zsh has had these features for years by Fweeky · · Score: 1

      Ah, bit more sensible if doxygen is configured WITHOUT_DOXYWIZARD, ta.

    16. Re:Zsh has had these features for years by John+Courtland · · Score: 1

      How can you forget K&R brace style vs BSD brace style?

      --
      Slashdot is proof that Sturgeon's Law applies to mankind.
    17. Re:Zsh has had these features for years by sootman · · Score: 1
      --
      Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
    18. Re:Zsh has had these features for years by Anonymous Coward · · Score: 0

      Emacs, logical? I don't think so.

    19. Re:Zsh has had these features for years by Anonymous Coward · · Score: 0

      1.) You can use < <(command) read variable
      2.) bash does support this, look at the bash manual (search for menu-complete)
      3.) That behaviour is mandated by the standard.
      4.) That is only the default behaviour, other people here have pointed out how to change it.

    20. Re:Zsh has had these features for years by Gunstick · · Score: 1

      ok. how do you code this in bash?

      ls -l | while read a b c d e f g h
      do
          [ "$h" = "" ] && continue
          count=$((count+1))
          size=$((size+e))
          files="$files '$h'"
      done
      echo "$count files totalling $size bytes:"
      echo "$files"

      To try in ksh (ubuntu):

      sudo apt-get install ksh
      ksh

      --
      Atari rules... ermm... ruled.
    21. Re:Zsh has had these features for years by Anonymous Coward · · Score: 0

      You forgot the fact that vista is OK

    22. Re:Zsh has had these features for years by JStegmaier · · Score: 1

      I also found the vi mode in zsh to be inferior to the equivalent in bash last time I tried it, but maybe it's improved since then.

      That's because Emacs's bindings are far more logical than Vi's, especially when running on FreeBSD instead of Linux. Oh, and indent with spaces.
      Did I miss anything?

      You forgot to mention how the new Bash works better on KDE 4.2 than on GNOME or KDE3.5.

    23. Re:Zsh has had these features for years by 0xABADC0DA · · Score: 1

      1.) You can use < <(command) read variable

      The 'read variable' part has to be a single command... it can't be compound, like a while or {..}. If you use eval then your variables are scoped to that subprocess. Furthermore, it's awkward.

      2.) bash does support this, look at the bash manual (search for menu-complete)

      Ok, I see that you can do this with a bind. There's no set option to do it, so you have to be fairly into tweaking your shell to do this. It's slightly annoying by adding an extra space and cycling back to the original text and ringing the bell, but presumably those can also be tweaked and are minor issues.

      3.) That behaviour is mandated by the standard.

      Bash isn't normally standards-compliant either unless using '-o posix', in which case it's only mostly compliant. So big deal. Zsh's behavior is better.

      4.) That is only the default behaviour, other people here have pointed out how to change it.

      Maybe so, but last time I tried I couldn't get bash to work anywhere near as well as zsh for history. In particular, I haven't seen any way to append to the history as the commands are entered instead of when the shell exits. So if your shell dies, for ex from power failure, all your history in that shell is list. Also the commands are not available in new terminals until you exit the shell they were typed into.

      So... 1 out of 4 isn't too bad?!

    24. Re:Zsh has had these features for years by Zalminen · · Score: 1

      2) Hell yes. I'm no command line guru, but still use it quite often.
      Cycle mode on tab completion would make my life SO much easier. Hmm, perhaps I should try moving to zsh...

    25. Re:Zsh has had these features for years by Anonymous Coward · · Score: 0

      zsh is for sure a great shell, but i stopped learning it after i discovered that they introduced a hole new set of conditionals. what for? it's still a shell, which means that if i have to do something complicated i'll make a script in scsh or guile anyways. besides this bash is undoubtedly a standard. once you get warm and comfy with it you can work on any operating system on this planet (well, DOS is not an OS, is it?). so i stick with bash. i also found the new completion package a nice approach because of it's modularity, while in zsh you got this huge file where everything seems to be mashed together. i guess it's mostly a question of taste.

  13. Screenshots? by dsginter · · Score: 5, Funny

    Does anyone have any screenshots? I always hate that when they post some great new upgrade without any screenshots.

    --
    More
    1. Re:Screenshots? by NonUniqueNickname · · Score: 5, Funny
      Here are a couple of screen shots. First one running as regular user. Second one running as root.

      $

      #

    2. Re:Screenshots? by Sir_Lewk · · Score: 0

      Screenshots of bash? Surely you troll.

      --
      "linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
    3. Re:Screenshots? by lawaetf1 · · Score: 4, Funny

      Here you go..

      [root@localhost ~]#

      --
      CommentBot 0.7a running with args "-module irritate,disagree -target random"
    4. Re:Screenshots? by Anonymous Coward · · Score: 0

      $ /bin/bash --version
      GNU bash, version 4.0.0(0)-release (i386-redhat-linux-gnu)
      Copyright (C) 2009 Free Software Foundation, Inc.

    5. Re:Screenshots? by MikeBabcock · · Score: 4, Funny

      I was really hoping someone would post a picture of a half-rotated Compiz cube with a bash shell running transparently on it.

      --
      - Michael T. Babcock (Yes, I blog)
    6. Re:Screenshots? by MMC+Monster · · Score: 4, Funny

      Anyone have a high-res screen shot? My fonts are raster based. :-(

      --
      Help! I'm a slashdot refugee.
    7. Re:Screenshots? by Lord+Ender · · Score: 0, Redundant

      Never log in as root! Sudo exists for a reason, kids.

      --
      A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
    8. Re:Screenshots? by shish · · Score: 1
      A screenshot of my custom theme:

      [shish] on [sakura] Sun Feb 22 04:45:19 ~/porn
      >

      --
      I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
    9. Re:Screenshots? by Anonymous Coward · · Score: 0

      Hey! How'd you get root on my system?!

    10. Re:Screenshots? by PitaBred · · Score: 1

      Naah, he jokes. It's just that some people have misfiring humor neurons and think that it's a troll instead.

    11. Re:Screenshots? by Anonymous Coward · · Score: 0

      I hate those types of prompts. It's wastes too much space with the brackets. I use:

      root@localhost:~#

    12. Re:Screenshots? by Anonymous Coward · · Score: 0

      Never log in as root! Sudo exists for a reason, kids.

      Yeah, so you can do "sudo -"!

    13. Re:Screenshots? by etnoy · · Score: 1

      Never log in as root! Sudo exists for a reason, kids.

      Yo've never heard of "sudo -i"?

      --
      Quantum hacker.
    14. Re:Screenshots? by kitgerrits · · Score: 3, Informative

      Warning, above post is NSFW!

      --
      "I was in love with a beautiful blonde once, dear. She drove me to drink. It's the one thing I am indebted to her for."
    15. Re:Screenshots? by dbIII · · Score: 1
      Cool! Now we can go "sudo bash".

      IMHO the answer is just to do as little in root as possible, block direct root logins from ssh and so on.

    16. Re:Screenshots? by dmsuperman · · Score: 4, Funny
      --
      :(){ :|:& };: Go!
    17. Re:Screenshots? by windsurfer619 · · Score: 2, Funny

      --
      :(){ :|:& };: Go!

      Does your sig still work? I heard they fixed that. You should try it.

    18. Re:Screenshots? by Lord+Ender · · Score: 1

      You must not work in a company with multiple unix admins. You sudo bash where I work and we'll fire your ass. When something breaks and nobody takes credit for it, everybody using sudo bash at that moment will be assumed equally liable.

      --
      A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
    19. Re:Screenshots? by AndrewBuck · · Score: 1

      Apparently as of version 3.2.39 they have not. This is the first, and last, time I run code found in a slashdot sig without first analyzing what it does. At least it only required a reboot.

      -Buck

    20. Re:Screenshots? by dbIII · · Score: 1

      We just have decent seperation where there are only two people it could be on any one server (yep - small org built from several smaller ones merging). I can see in environments where a lot of people know the root passwords that it could be a problem, but where everyone that knows the password for a system is easily found and accountable I do not see it as one.

    21. Re:Screenshots? by tobiasly · · Score: 1

      I've been trying for five minutes to upload such a photo, converted to ASCII art via jp2a, but Slashdot's junk filter keeps blocking it. Just trust me that it would have been hilarious.

    22. Re:Screenshots? by Anonymous Coward · · Score: 0

      Yeah, that would make it easier to decide whether I want to buy a copy - I have the free trial version :(

    23. Re:Screenshots? by Splab · · Score: 1

      Be glad it's only a fork bomb...

    24. Re:Screenshots? by berend+botje · · Score: 1

      I've only found a high-res shot from the Apple OS X port of Bash.

    25. Re:Screenshots? by Viree · · Score: 1

      Never log in as root! Sudo exists for a reason, kids.

      Like for this http://xkcd.com/149/?

      Sorry, couldn't resist.

    26. Re:Screenshots? by Lord+Ender · · Score: 1

      If you were running things properly, there would not BE a root password.

      --
      A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
    27. Re:Screenshots? by ch33zm0ng3r · · Score: 1

      Nice! I'm setting this as my new wallpaper.

    28. Re:Screenshots? by dbIII · · Score: 1

      Oh grow up, and get enough experience to not spout bullshit like that. I know Gentoo and Unbuntu are the flavours of the month but not all *nix is like that. You can run things properly without putting Gentoo on everything and having to sudo whenever you want to change anything that needs root access.

    29. Re:Screenshots? by Lord+Ender · · Score: 1

      Grow up? Ha! A talentless admin from a small IT department who doesn't even understand how to operate a unix system properly is telling me to grow up? Truly funny.

      If you use unix a bit longer, you may learn that running Ubuntu or Gentoo or whatever is not a requirement for hardening a unix system. You can harden anything, whether it ships that way by default or not.

      You're one of those noob admins who just runs everything at its default, I see. Is Internet Explorer working out well for ya?

      --
      A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
    30. Re:Screenshots? by dbIII · · Score: 1
      Absolute statements that are wrong in many cases tend to indicate a lack of maturity and/or experience.

      It is however much quicker if less polite to convey the same thing by saying "grow up". Unfortunately that has led you to believe that it's time to start a childrens sandpit fight of name calling like the crap above.

      While sudo is useful and is fashionable now I disagree that it should be used everywhere by everyone and everything - so I see your absolute as a mistake of a newbie who thinks an exciting new tool was there forever.

      What else do you expect me to do when some newbie tells I don't know how to run things properly and spouts some bullshit that may be right on his home Gentoo system and the carefully set up production environment that others have put together for him but does not apply everywhere. There are circumstances where it's useful, circumstances where it JUST DOES NOT MATTER and there are circumstances where that tool is not even available at all.

      Why use sudo merely as a trace tool when you have people taking full responsibility for their own actions and no opportunity for whiny finger pointers to point at anyone anyway? Do you make your developers put sudo at the start of every line on their own dev boxes when they need to be root? What if they are on embedded systems that don't even have sudo? Now the light should be dawning and you should be starting to understand that stating absolutes based on limited experience and insulting those who know it is bullshit is somewhat annoying.

  14. An ode to Bash by timpintsch · · Score: 0

    So you like to type in script, No forgiveness when a space is skipped, It doesn't matter, I'm hard up for cash. Thank goodness I have patience, for the love of BASH

  15. Re:So? by brasspen · · Score: 4, Insightful

    The day Ruby or Python takes over from the boot grub loader for the initialization of init levels in Linux on start up is the day your statement makes sense. Until then, I think people with your attitude love one tool too much. If you don't understand BASH, you don't really understand Linux. I think OS start up is a serious script.

  16. Note for sysadmins by 93+Escort+Wagon · · Score: 4, Funny

    With your production boxes, it's generally recommended that you wait for Bash 4.0 SP1 before deploying.

    --
    #DeleteChrome
    1. Re:Note for sysadmins by Anonymous Coward · · Score: 0

      Or even SP2

    2. Re:Note for sysadmins by Hatta · · Score: 1

      Bash 4.0 is intended for early adopters. Most users should wait for Bash 4.2.

      --
      Give me Classic Slashdot or give me death!
    3. Re:Note for sysadmins by ardor · · Score: 1

      For marketing reasons, the developers prefer to call Bash 4.0 SP1 "Bash 7" and sell it as a full-price product.

      --
      This sig does not contain any SCO code.
  17. Bourne Shell by russotto · · Score: 2, Insightful

    If you want your scripts to be compatible with just about every Unix, you still need to stick with /bin/sh (yes, I know, it's a compatibility mode). If you don't, might as well use a better scripting language.

    1. Re:Bourne Shell by QuoteMstr · · Score: 0

      Erm, on what modern system is bash not available?

    2. Re:Bourne Shell by thermian · · Score: 1

      There are some large software packages that can't use bash without problems. Take the Nemo Stellaer Dynamics Toolbox for instance(http://bima.astro.umd.edu/nemo/). When I was using that a couple of years ago it needed a fair bit of messing about to get it to work with bash.

      --
      A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' - D. Adams
    3. Re:Bourne Shell by Anonymous Coward · · Score: 0

      Erm, on what modern system is bash not available?

      BSD for one.

    4. Re:Bourne Shell by Tony+Hoyle · · Score: 3, Insightful

      Solaris 9 (10 is *far* from universal, hell, even 8 is pretty common). HPUX. Tru64. That's three off the top of my head.

      People have ported GNU to them but you just can't rely things like bash being there - you have to be able to work with the out of the box environment.

    5. Re:Bourne Shell by Anonymous Coward · · Score: 0

      Native Windows.

    6. Re:Bourne Shell by TheRaven64 · · Score: 4, Insightful

      Not available? Not many. Not installed as standard? *BSD, Solaris, AIX, and any Linux that isn't GNU/Linux. POSIX mandates the existence of /bin/sh and a set of commands it must understand. Any POSIX system will have this, and it's possible to write complex scripts using only these features. Using bash extensions means that you are writing a GNU shell script, not a portable shell script. This may be fine for you, but you've just added another dependency to your program.

      --
      I am TheRaven on Soylent News
    7. Re:Bourne Shell by vlm · · Score: 2, Funny

      Tru64. That's three off the top of my head.

      What, three users or three installed servers?

      Tru64 has been abandonware for four long years and will have no commercial support in only three years.

      To quote the great wikipedia:

      In December 2004, HP announced a change of plan; they would instead use the Veritas file system and abandon the Tru64 advanced features. In the process, many of the remaining Tru64 developers were laid off.[8]

      In July 2007, HP stated that they would continue to support Tru64 UNIX until at least 2012.

      You'd get more support by complaining that VMS, MVS/370, and TRS-DOS 1.3 don't come with BASH.

      --
      "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
    8. Re:Bourne Shell by dgatwood · · Score: 3, Insightful

      Out of the box? My guess is "almost all of them", at least where BASH 4 is concerned. Outside of the Linux community, BASH 4 will pretty much be stillborn. I expect close to zero adoption.

      Why? GPL v3. The *BSD community is working hard to replace everything the FSF produces with BSD-licensed code because GPL v3 is so offensive to them. They're well on their way even in hard-to-fill spaces like compiler technology. With shells, they already have several viable replacements, so there's no point in continuing to drag along the licensing baggage that is BASH. They'll just include Zsh and pdksh instead and most people won't care. The folks who do can compile and build BASH themselves. I'd expect it to be rejected by many of the corporate-backed UNIX/Linux distros as well.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    9. Re:Bourne Shell by harry666t · · Score: 1

      From what I recall, all the *BSDs, for example.

      Yeah, in Linux world, "portability" could be defined as "it runs on Red Hat, Debian, and even Gentoo!"

    10. Re:Bourne Shell by nabsltd · · Score: 1

      There are some large software packages that can't use bash without problems.

      This is a problem with the software package, not with bash.

      If the software has a script it runs that requires 100% sh compatibility, then the script should start with "#!/bin/sh", or should be invoked with "sh scriptname".

    11. Re:Bourne Shell by Hatta · · Score: 1

      Embedded systems with Busybox for one. Though 'ash' is at least somewhat compatible with 'bash'.

      --
      Give me Classic Slashdot or give me death!
    12. Re:Bourne Shell by OneSmartFellow · · Score: 1

      Only weenie heads use anything other than BASH; just ask Melvin !

    13. Re:Bourne Shell by Anonymous Coward · · Score: 0

      You can compile it or install a package in all BSDs, but why would you want to soil your system with proprietary GNUsh???
      (Pd)ksh has never let me down.

    14. Re:Bourne Shell by larry+bagina · · Score: 1

      The debian installer uses dash. AIX uses ksh.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    15. Re:Bourne Shell by Deagol · · Score: 2, Interesting

      Apparently, bash's own compatibility mode leaves a lot to be desired. There's no end to people on FreeBSD lists who bitch about porting some script from Linux, to have someone point out that /bin/sh on Linux 99.9% of the time equals /bin/bash in compatibility mode. Best to code for strict Bourne shell syntax even if you use Linux, since you can be reasonably assured that it will work nicely on other systems. Not sure what the de-facto open source Bourne shell clone is. Perhaps "ash" is close enough, as the various BSD's use it (or a modification of it) as the system /bin/sh.

    16. Re:Bourne Shell by DarkOx · · Score: 2, Informative

      The Slackware standard for init scripts and other system utils done is shell is that it should run on ash. If it runs on ash it will run on bash. The installation media used to, and still does? use ash while an installed system uses bash as the interpreter. So I agree with you its reasonable to code to ash for shell scripts if portability to othe *NIX like systems or running in striped down cases like installation environments is any concern.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    17. Re:Bourne Shell by r7 · · Score: 2, Interesting

      use a better scripting language

      That's what I've been wondering. Bash is fine for the command-line but not such a good choice for scripts due to compatibility issues. It certainly isn't a good choice of scripting language compared to /bin/sh. Given the number of changes bash has had over the years it would seem to be a kitchen sink of every feature anyone wanted to add (though not necessarily use). POSIX is protecting /bin/sh from this sort of feature creep but there are still several bugs in "bash --posix" (sh mode).

      I also wonder about feaures like associative arrays in shells. Obviously someone wanted to code it, but a shell seems like the wrong tool for any job needing an array. Is Bash's feature creep just bloat, motivated by some shell programmer's fears of learning a more appropriate scripting language like Python or Perl? I have to say it seems that way given that +99% of Bash scripts are simply the result of the script writer's lack of familiarity with the differences between bash and sh.

    18. Re:Bourne Shell by Anonymous Coward · · Score: 0
      Erm, on what modern system is bash not available?

      Embedded Linux systems with ash or busybox rather than bash.

    19. Re:Bourne Shell by Anonymous Coward · · Score: 0

      FreeBSD has bundled sh (a small Bourne shell, BSD-licenced) and tcsh (a very reasonable user shell, though not that nice to script; also BSD licenced) for ages.

      If you want bash, it's available as a package or port, alongside zsh and the like.

    20. Re:Bourne Shell by Anonymous Coward · · Score: 2, Insightful

      I'd expect it to be rejected by many of the corporate-backed UNIX/Linux distros as well.

      Unless there are huge incompatiblities with Bash 3.0 (which there aren't), the distros will pick it up at the normal rate. GPLv3 doesn't scare the corporate-backed distros. Why should it?

  18. Re:So? by turbidostato · · Score: 1

    "I think OS start up is a serious script."

    Surely it is.

    You must think it's such a big pity Bash is not used on OS start up...

  19. Re:So? by QuoteMstr · · Score: 4, Informative

    What the fuck are you talking about? In the real world, shell scripts are used all the time. Despite their failings relative to more complex languages like Python and Perl, shell scripts are very easy to generate from repeated manual invocations of command lines.

    In other words, to scratch an itch with a Python script requires writing your command over again. With a shell script, you can build on the commands you've already typed. Shell scripting is the original RAD, and remains very useful today.

  20. Re:So? by QuoteMstr · · Score: 2, Informative

    /etc/init.d/acpid: Bourne-Again shell script text executable
    /etc/init.d/btseed: Bourne-Again shell script text executable
    /etc/init.d/bttrack: Bourne-Again shell script text executable
    /etc/init.d/capi: Bourne-Again shell script text executable
    ...
    Err, what? Shell scripts are used all the time. Even upstart services are still often written as shell scripts. Really, why all the anti-shell hostility around here?

  21. Re:So? by afabbro · · Score: 1

    But the scripting community has moved on,

    "The scripting community"...that has to be the funniest phrase I've heard in a long time.

    --
    Advice: on VPS providers
  22. After bootstrapping... by Dareth · · Score: 2, Funny

    After bootstrapping the new compiler with the old compiler, you can then use your new compiler to compile the new compiler code.

    If this bothers you, stay away from recursion!

    --

    I only look human.
    My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
    1. Re:After bootstrapping... by timeOday · · Score: 1

      And if it doesn't bother you (from a security standpoint), perhaps it shoud: oblig. Ken Thompson, "Reflections on Trusting Trust." (Short and very sweet).

    2. Re:After bootstrapping... by QuoteMstr · · Score: 4, Interesting

      Broken link. Try this: Reflections on Trusting Trust. It's the most frightening security paper of the last 30 years.

    3. Re:After bootstrapping... by Anonymous Coward · · Score: 0

      I didn't read it but I assume it's the thing about how a compiler can insert malware into the program it's compiling hence making everything we use have malware.

      If it happened by now I think we'd have noticed the massive botnet traffic by now.

    4. Re:After bootstrapping... by Anonymous Coward · · Score: 0

      Then read 'Countering "Trusting Trust"'

      http://www.schneier.com/blog/archives/2006/01/countering_trus.html

    5. Re:After bootstrapping... by JoCat · · Score: 2, Funny

      To learn recursion you must first learn recursion.

    6. Re:After bootstrapping... by ShecoDu · · Score: 1
    7. Re:After bootstrapping... by Anonymous Coward · · Score: 0

      I read this tonight. It's great. Thanks so much. I'll keep this forever!

  23. Re:So? by jetsci · · Score: 1

    I'm curious, in your opinion what is a better use of my learning time? I'm learning bash scripting and python scripting at the moment as I am a sysadmin with a lot of time. What do you propose I learn instead?

    --
    Bored at work? Play Game!
  24. Re:So? by QuoteMstr · · Score: 1

    Get off your high horse. Upstart works equally well with shell scripts for events. Shell scripting is plenty useful and is here to stay. The only reason you'd shun it is if you were a cocky newbie who hasn't yet learned to not re-invent the wheel.

  25. What's new? by dfn_deux · · Score: 1

    Can someone post a link to a simple "What's New" doc? I'm not gonna go combing through the code to see if they've fixed my bug.

    --
    -*The above statement is printed entirely on recycled electrons*-
    1. Re:What's new? by gzipped_tar · · Score: 1

      http://tiswww.case.edu/php/chet/bash/CHANGES

      Not a summary but a listing of incremental changes i.e. changes between 4.0 and 4.0-rc1, rc1 and beta2, beta2 and beta1, etc.

      --
      Colorless green Cthulhu waits dreaming furiously.
  26. Re:Seems like a bad acronym by Anonymous Coward · · Score: 0

    I know you are kidding, but the award of really bad program name should go to the WebDAV client "cadaver".

    And I'm tempted to name my WebDAV server "morgue" ;)

  27. Re:So? by Luyseyal · · Score: 1

    No kidding. I'm not a huge fan of bash scripting, but as a big commandline user, I am looking forward to the ** globbing.

    -l

    --
    Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
  28. Re:So? by Anonymous Coward · · Score: 0

    "acpid: POSIX shell script text executable"

    Very few OSes use bash for init.d scripts.

  29. Re:So? by cheater512 · · Score: 3, Informative

    Gentoo uses bash for their init scripts citing reasons of speed.

    Yeah it does show.

  30. Fixed! by jgeiger · · Score: 1

    The new major release fixes several remaining bugs in the 3.x releases, and introduces a bunch of bugs.

  31. Re:So? by Hatta · · Score: 1

    Do those actually require bash? Or are they 'sh' scripts that 'file' happens to call bash scripts? This isn't anti-shell hostility, it's anti-linux centric non-standard bash scripts hostility.

    --
    Give me Classic Slashdot or give me death!
  32. Teh snappy? by Zaurus · · Score: 0, Offtopic

    But is it snappier?

  33. mostly agree by Trepidity · · Score: 1

    I do find having moderate lightweight programmability in a shell to be useful, for writing one-off things on the command line: things like doing some operation on file_X for X=01 to 99. But for anything more significant, I find myself always writing a Perl script or something.

    1. Re:mostly agree by fm6 · · Score: 1

      That's exactly my attitude. Everybody who responded to my post seems to read it to mean "shell scripts are obsolete." You all missed the part where I said that shell scripts still have their uses. They just don't have enough uses for anybody to care about an overhaul of any shell language.

  34. Re:So? by init100 · · Score: 1

    Shell scripting is obsolete technology.

    Hardly. Shell scripting is still useful for all those simple tasks that are not much more than a couple of linked shell commands, where Python or Ruby would be major overkill. On the other hand, I'd never use Bash to write anything complicated, as Python is much easier for that.

  35. I mostly do that in other languages, too by Trepidity · · Score: 1

    Maybe it's a weird way to go about it, but when I write my shell-script-like Perl scripts, I start them out similarly by just building on commands I've already typed, wrapped in system(). Slightly heavier-weight syntax, but not by much, and allows me to use all the rest of Perl, which makes some things easier.

    It does provide a portability route if I want one: I can convert all the system("mv whatever") calls to use the proper Perl OS-abstraction libraries. But you don't have to start out with those.

  36. DVD? by dixiecko · · Score: 0, Offtopic

    Can I order DVD from bashmall.com ?

  37. BASH 4.0? by Anonymous Coward · · Score: 0

    Bourne bourne bourne bourne again!

    Of course I wouldn't wait for 4.2, as someone pointed out above, but rather I would stick to using 3.5, even though really they are only at 3.2.

  38. Re:So? by MikeBabcock · · Score: 2, Informative

    I'm sorry, but /etc/rc.d/rc.sysinit is certainly not empty on my Fedora boxes. It also contains a lot of good functionality that matters to system start-up.

    --
    - Michael T. Babcock (Yes, I blog)
  39. Re:So? by EddyPearson · · Score: 2, Insightful

    Do you use bash on a day to day basis?

    I love using bash scripting inline, so to speak. The speed that you can get complex things done on the commmand line (and you might be surprised how much you can do with a little ingenuity) is due in no small part to the flexibility of the bash scripting language.

    Sure, you could fire up vi (or perhaps nano?) and write a "serious" script to help you get the job done, but my way's quicker.

    --
    You feel sleepy. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise.
  40. something resembling homepage by richlv · · Score: 2, Insightful

    it would be quite cool if they could set up at least something something resembling homepage.
    you know, the thing with announcements, news, and, ooooh, release notes !
    wiki probably would be too much to ask.

    --
    Rich
    1. Re:something resembling homepage by Tweenk · · Score: 5, Funny

      Are you smoking something? This is a GNU project. The "web page" is actually a facade to appease the unenlightened. Here is a Web 1.0 concept mapping for you:

      news page -> "announce" mailing list
      wiki -> "user" mailing list, documentation
      developer forum -> "dev" mailing list
      release notes -> in the tarball!

      --
      Those who would give up liberty to obtain working drivers, deserve neither liberty nor working drivers.
    2. Re:something resembling homepage by cranky_slacker · · Score: 1

      It's funny and true.

  41. CORRECTION by grayn0de · · Score: 1

    ... certain users are not yet ready...

    ...MOST users.

    1. Re:CORRECTION by Anonymous Coward · · Score: 0

      "...MOST users".

      And most of those MOST users are not even ready for Windows. They struggle even in that environment.

    2. Re:CORRECTION by multisync · · Score: 2, Informative

      ...MOST users.

      Judging by the number of Windows machines that are active members of botnets, it's not just the Linux desktop "MOST users" are not ready for.

      --
      I don't care why you're posting AC
    3. Re:CORRECTION by Anonymous Coward · · Score: 0

      We clearly need yet another car analogy here. Most people are driving SUVs that are infested by vermin. When the vermin get in the engine and the vehicle starts slowing down, they usually just ignore it until it's crazy slow, then buy a new SUV. It sure will be fast... for a little while. Okay, for about 4 minutes.

    4. Re:CORRECTION by Jurily · · Score: 4, Insightful

      ...MOST users.

      To be fair, most users have trouble setting the clock on a VCR.

    5. Re:CORRECTION by Anonymous Coward · · Score: 0

      That's because they all have hard disc recorders...

    6. Re:CORRECTION by geoffball · · Score: 1

      What's a VCR?

    7. Re:CORRECTION by vihung · · Score: 1

      Setting the clock on a VCR is absolutely horrible from a usability point of view. I, personally, am quite technically competent (I read Slashdot, after all!), I know how to set the clock on my VCR, and yet I refuse to do so because it just feels so wrong

    8. Re:CORRECTION by Anonymous Coward · · Score: 0

      Possibly because most people no longer use a VCR.

    9. Re:CORRECTION by jon207 · · Score: 1

      To be fair, on many VCR it is more hard to set the clock than it is to install an OS on many computers, because VCR's user interfaces are so badly designed and counter-intuitives.

      --
      "Freedom can only be the whole of freedom; a piece of freedom is not freedom." Max Stirner
    10. Re:CORRECTION by Anonymous Coward · · Score: 0

      ...MOST users.

      To be fair, most users have trouble setting the clock on a VCR.

      You can set the clock on VCR ? Amazing I thought that those digits were supposed to flash on and off all the time. Who knew ?

  42. true... by VON-MAN · · Score: 1

    And the only (partial) way out of this problem I know of is screen. It offers a way of not having to close a session but to disconnect from it and later connect. You still cannot use multiple session with one user and keep all history, but you i.e. can run your primary commands on you screen session and keep that one running all the time (and keep your important work). Working that way is also a nice way to keep focused. Need to keep your machine running, obviously.

    1. Re:true... by Froze · · Score: 1

      Yes, I do use screen (probably the single greatest development since the invention of the command line) and it helps but when you are running it on a remote machine that is rebooted you still have the same problems. Now if someone would just fix bash history and fix screen so that it knows how to redirect GUI items based on where the CLI was acted on I would be a very happy person indeed.

      --
      -- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
    2. Re:true... by Anonymous Coward · · Score: 0

      Use i.e. as a stand-in for "that is." Use e.g. when you mean "for example."

    3. Re:true... by lilomar · · Score: 3, Funny

      Use i.e. as a stand-in for "that is."

      I prefer to use Firefox.

      --
      The creator of this post (Jacob Smith) hereby releases it, and all of his other posts, into the public domain.
    4. Re:true... by Anonymous Coward · · Score: 0

      Don't give up your day job to become a comedian.

    5. Re:true... by Provocateur · · Score: 1

      That is his day job, you insensitve clod!

      --
      WARNING: Smartphones have side effects--most of them undocumented.
    6. Re:true... by amRadioHed · · Score: 3, Interesting

      Or do "set -o inc_append_history" in zsh.

      (I'm not sure if the option is case sensitive. It may need to be in CAPS, the lameness filter made me change it)

      --
      We hope your rules and wisdom choke you / Now we are one in everlasting peace
    7. Re:true... by x2A · · Score: 1

      Even more of a reason why to not give it up to become it! That's just hassle, especially in todays economic climate. It's sound advice, dude!

      --
      The revolution will not be televised... but it will have a page on Wikipedia
    8. Re:true... by RichiH · · Score: 1

      zsh does not care. You are free to

        setopt InC___Ap__PEND_h_i_s_t_o_RY

      if you want to. Underscores are ignored, as is case.

  43. FISH & ZSH by Anonymous Coward · · Score: 0

    I love BASH, and it's my primary shell, but other shells have some really cool features. ZSH can have status bars and some cool syntax for lazy people and FISH has built in syntax highlighting...

    1. Re:FISH & ZSH by QuoteMstr · · Score: 1

      Thanks. I'll have to play with fish a bit. It certainly seems interesting.

    2. Re:FISH & ZSH by Anonymous Coward · · Score: 0

      You're very welcome. I actually made an Ubuntu Brainstorm Idea for this in Bash here. It looks to me that it would be necessary to modify GNU readline, however. I think that it should be possible to put it in ZSH as a part of a configuration but I don't know enough about ZSH to do it and don't (right now) have the time to learn...

  44. Re:So? by value_added · · Score: 2, Insightful

    Tons of fun for a certain kind of hacker, but not of any interest for people writing serious scripts.

    Most serious scripts are (and continue to be) written using /bin/sh. Maybe your definition of serious is something different?

    But the scripting community has moved on, and doesn't really care that Bash or Csh now have features that other scripting languages acquired decades ago.

    Huh? Some of the new features are welcome for interactive use, and bash is extremely popular in that regard. Feature parity (in a general hand-wavy sense) doesn't exist between bash, csh, zsh, etc., so decades later, the choice of shells remains important, as does continued development.

    Personally I use bash (with plenty of Perl one-liners thrown in for good measure), but I'd be misguided to think that bash (or Perl) is available everywhere, or didn't concede that other shells do certain things far better.

  45. Re:So? by zx-15 · · Score: 4, Interesting

    Weird, because Debian moving away from bash to dash for exactly the same reasons.
    http://www.nabble.com/Making-init-scripts-use-dash-td4458217.html

  46. Ant-style ** globbing by Rayban · · Score: 4, Funny

    Instead of rm -rf /, we can now just say

    rm -f /**

    Now that's an improvement!

    --
    æeee!
    1. Re:Ant-style ** globbing by gzipped_tar · · Score: 4, Interesting

      The scary thing "rm -f /**", when used with the new shopt "globstar", removes all non-directory files while preserving the directory skeleton. It's kinda like vaporizing everyone in the town while leaving all the empty buildings and cars intact...

      --
      Colorless green Cthulhu waits dreaming furiously.
    2. Re:Ant-style ** globbing by againjj · · Score: 2, Informative
      So, http://www.mail-archive.com/cygwin@cygwin.com/msg94439.html states:

      There is a new shell option: `globstar'. When enabled, the globbing code treats `**' specially -- it matches all directories (and files within them, when appropriate) recursively.

      which would imply the buildings and cars go too. See also: http://www.bash-hackers.org/wiki/doku.php/bash4

    3. Re:Ant-style ** globbing by ardor · · Score: 2, Funny

      Ah! A command-line neutron bomb?

      I am sure Linux is ready for the desktop now.

      --
      This sig does not contain any SCO code.
    4. Re:Ant-style ** globbing by Anonymous Coward · · Score: 0

      I think I have seen that movie...

    5. Re:Ant-style ** globbing by Qzukk · · Score: 2, Interesting

      Without -r, rm will error instead of deleting directories, however these errors will not stop rm from removing the remaining files on the command line.

      The buildings and cars remain due to malfunction, not design ;)

      --
      If I have been able to see further than others, it is because I bought a pair of binoculars.
    6. Re:Ant-style ** globbing by WhitefishMT · · Score: 5, Funny

      So they've finally perfected the Gnu-tron bomb!

    7. Re:Ant-style ** globbing by svank · · Score: 1

      Ah! A command-line neutron bomb?

      I am sure Linux is ready for the desktop now.

      I'm sure we'll now see greater uptake by the military.

    8. Re:Ant-style ** globbing by Rick+Genter · · Score: 1

      You should get a +5, Funny for that.

      --
      Don't underestimate the power of The Source
    9. Re:Ant-style ** globbing by Anonymous Coward · · Score: 0

      Guess there's only one way to settle this argument...

      NO CARRIER

    10. Re:Ant-style ** globbing by Anonymous Coward · · Score: 0

      find / -type f | xargs rm -f

    11. Re:Ant-style ** globbing by Anonymous Coward · · Score: 0

      So they've finally perfected the Gnu-tron bomb!

      I suspect the MS-CP will have something to say about that . . .

      --
      END OF LINE.

    12. Re:Ant-style ** globbing by Anonymous Coward · · Score: 0

      Doesn't work with newlines in file names. This kind of things should always be done via find / -type f -exec rm {} \;.

    13. Re:Ant-style ** globbing by Anonymous Coward · · Score: 0

      for fuck's sake, dude, if you want to be cool and and correct someone else's crappy find command, then at least do it properly.

      Problems with your line:

      find / -type f -exec rm {} \;.

      1) using exec.
      it's bad. it's not recommended. it's insecure. it even says so in the fucking man page.
      furthermore it's fucking slow. it forks a process for every found file. fucking brilliant, solution, eh?

      2) {}
      this should be '{}'. figure yourself out why.

      a proper solution:

      find / -type f -print0 |xargs -I -0 '{}' rm -f {}

    14. Re:Ant-style ** globbing by Provocateur · · Score: 1

      ...for those who would prefer to Gnuke the site from orbit...

      --
      WARNING: Smartphones have side effects--most of them undocumented.
    15. Re:Ant-style ** globbing by dkf · · Score: 1

      The scary thing "rm -f /**", when used with the new shopt "globstar", removes all non-directory files while preserving the directory skeleton. It's kinda like vaporizing everyone in the town while leaving all the empty buildings and cars intact...

      On a large directory structure it will actually (partially) fail in a nasty heap, since you probably won't be able to fit the list of all files (and directories and ...) into the command line space. If you want to destroy all the files in the world, you need to be more sophisticated:
      find / -type f -print0 | xargs -0 rm -f

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    16. Re:Ant-style ** globbing by chuckymonkey · · Score: 1

      You owe me a Gnu keyboard.

      --
      "Some books contain the machinery required to create and sustain universes."-Tycho
    17. Re:Ant-style ** globbing by gzipped_tar · · Score: 1

      On a large directory structure it will actually (partially) fail in a nasty heap, since you probably won't be able to fit the list of all files (and directories and ...) into the command line space.

      I figured it out that too after I posted the reply. The new glob is a nice feature though, when the directory tree is not too high or crowded.

      --
      Colorless green Cthulhu waits dreaming furiously.
    18. Re:Ant-style ** globbing by againjj · · Score: 1

      You're right -- ** sorts, which means /** would cause /bin to be listed before /bin/*, so rm would fail to delete /bin. Whoops.

  47. I hate [T]CSH by Khopesh · · Score: 5, Insightful

    One of my favorite bookmarks, Csh Programming is Considered Harmful, is very useful for shell scripting in Bourne, Csh, and Bash. Oh, and it's also a good reminder of why you should never write csh scripts.

    In my experience, the only [t]csh users out there are those who used it back in the day before there were other options, or those who are so embedded in the C/C++ world that they thought it a good idea to use a C/C++ -styled shell. That's fine, use that shell. DON'T write scripts in it though. It's annoying. (More annoying: ln -s /bin/csh /bin/sh ... this breaks TONS of things as /bin/sh must be posix-compliant. Csh doesn't even want (or try) to do that!)

    --
    Use my userscript to add story images to Slashdot. There's no going back.
    1. Re:I hate [T]CSH by cababunga · · Score: 1

      In my experience, the only [t]csh users out there are those who used it back in the day before there were other options, or those who are so embedded in the C/C++ world that they thought it a good idea to use a C/C++ -styled shell.

      FWIW C shell syntax isn't even remotely similar to C. In my experience people using C shell and derivatives are coming from IRIX systems, where csh was the default shell.

      That's fine, use that shell. DON'T write scripts in it though.

      That's the problem. If people use tcsh as an interactive shell, there is no way you can convince them to use bash for scripting, because tcsh is all they know. And of course here we have all those problems described in the article you've mentioned.

    2. Re:I hate [T]CSH by osu-neko · · Score: 1

      In my experience, the only [t]csh users out there are those who used it back in the day before there were other options...

      Yes. This phenomenon is also responsible for the continued usage of vi and other primitive behaviors.

      (Not that there's anything wrong with that, speaking as someone who uses joe and alters all my syntax highlighting to replicate the same color scheme I used in Turbo C under DOS.)

      --
      "Convictions are more dangerous enemies of truth than lies."
    3. Re:I hate [T]CSH by dargaud · · Score: 1

      As an ex tcsh user, I just wanted to ask, are csh/tcsh still being developed ?

      --
      Non-Linux Penguins ?
  48. Re:So? by nabsltd · · Score: 1

    On my Fedora Core 6 box, 44 of the 75 scripts in my /etc/rc.d/init.d start with:

    #!/bin/bash

    For Fedora 10, 31 of 47 scripts start with that line.

    There are some non-Fedora packages on the boxes, YMMV, etc.

  49. Re:Seems like a bad acronym by Anonymous Coward · · Score: 0

    and I thought slurpd was bad :)

  50. Re:So? by fm6 · · Score: 1

    I did say that shell scripts still had their uses. But does that make new shell features worth caring about? Will any of them find their way in the boot scripts?

  51. Re:So? by fm6 · · Score: 1

    shell scripts are very easy to generate from repeated manual invocations of command lines.

    Very simple shell scripts, which don't use any of these fancy new features. I'm still not hearing a reason I should care about a major update to Bash.

  52. Re:So? by Anonymous Coward · · Score: 3, Insightful

    You're an idiot.

    The shell is my file manager, and my entire dev toolchain works from the shell. Shell scripting is better suited to linking together unix commands that pipe text between one another. I don't particularly want any scripting interpreters other than bash and awk to be _required_ on my systems. I like lua and javascript, some folk prefer perl, python or ruby but nobody is getting very far on a unix-like system without /bin/sh and the de-facto standard for that is bash.

  53. Re:So? by fm6 · · Score: 1

    I believe you're the kind of person I was referring to when I said "tons of fun for a certain kind of hacker." But tell me, is this latest update to Bash going to have any sort of impact on your productivity? Or is it just more kewl stuff that you'll enjoy playing with?

  54. Backward Compatibility by RichiP · · Score: 3, Interesting

    I'm seeing release candidate versions of bash 4 in the SRPMS dir for Fedora testing. It should be easy to rebuild it on Fedora 10 and install it, but I'd like to know if it would break existing scripts.

    Does anyone know if it has any backward compatibility issues?

    1. Re:Backward Compatibility by slash.duncan · · Score: 1

      There's a thread up on gentoo-dev warning about one such compatibility issue. bash-4.0 is apparently in the Gentoo tree already (I've not actually checked) but is and will remain for the time being hard-masked.

      The compatibility issue in question is escaped semicolons in subshells, apparently done either as part of the new case expansion stuff (suggested in-thread) or for better POSIX compatibility (suggested by the new features list in the release announcement), but it's backward incompatible with enough ebuilds/eclasses/etc to cause Gentoo problems, thus the keeping it hard-masked until the issues are worked thru.

      Here's a link to the thread as seen on gmane:

      http://comments.gmane.org/gmane.linux.gentoo.devel/59774

      --
      Duncan
      "Every nonfree program has a lord, a master,
      and if you use the program, he is your master."
      R Stallman
  55. Re:So? by fm6 · · Score: 1

    Most serious scripts are (and continue to be) written using /bin/sh. Maybe your definition of serious is something different?

    Scripts written in a serious language. Maybe you've been using sh so long, it's more efficient for you to work in it than in any more modern language. (Rather like an old Bell Labs hand I used to know who could edit faster in ed than any of us could in vi or emacs.) But the traditional shell language is still very klunky and limited compared to later scripting languages.

    I still write the odd shell script myself. But if I need to do anything at all complicated, I switch to Perl. And even Perl is showing its age. (If writing scripts were a bigger part of my job, I'd learn Ruby.) But it's still more sophisticated than sh, bash, or csh.

  56. Sweet! Already in MacPorts and Cygwin! by Anonymous Coward · · Score: 0

    Wow, that was fast!

  57. ** globs by Deleriux · · Score: 1

    I hope to god nobodies got a ** typo in an old script because that could be troublesome.

    Even worse it could be simple enough to ** in error on the prompt.

    1. Re:** globs by gzipped_tar · · Score: 1

      The ** glob is expanded only when the option "globstar" is set. If backward compatibility is a key issue for you, be sure not to set it when running old scripts.

      --
      Colorless green Cthulhu waits dreaming furiously.
  58. Re:So? by hobbit · · Score: 1

    Get off my lawn. Shell scripting? What's wrong with machine code? Damned cocky newbies.

    --
    "Wise men talk because they have something to say; fools, because they have to say something" - Plato
  59. Re:So? by larry+bagina · · Score: 1

    That's doubly interesting, given that a couple weeks ago in the portable shell scripting book review, some people were insisting that everyone should tell other shells (and portability) to fuck off and just use bash (and it's extensions).

    --
    Do you even lift?

    These aren't the 'roids you're looking for.

  60. Feeding a troll by Froze · · Score: 3, Insightful

    Yes, I am complaining about the default behavior.

    How about if we made the default for mv to delete blocks as they were copied and not wait to delete to original until a full copy was made. This would be 'good' (more efficient) most of the time and break in strange corner cases, losing the users data (not a good thing^TM).

    The default behavior should *NOT lose data*. To do so is bad UI design.

    --
    -- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
  61. Re:So? by Anonymous Coward · · Score: 0

    Gentoo uses bash for their init scripts citing reasons of speed.

    Of course, more time left for compiling.

  62. Yes!!! by commodoresloat · · Score: 5, Funny

    This is definitely the turning point; the Register just last week published an article indicating that the one thing stopping most users from migrating from Windows was the lack of support for the `**' special glob pattern.

  63. Re:So? by Vectronic · · Score: 1

    "...who hasn't yet learned to not re-invent the wheel."

    Are you serious? re-inventing the wheel is pretty much the basis of our existence.

    You can claim otherwise, but you'd better pull up, naked, riding on some wooden rollers, shaving your beard by chewing it off.

    BASH et al, certainly has it's place, but considering the article is about BASH 4.0, even the people who originally developed this wheel, thought it wasn't good enough as is.

  64. Re:So? by the_one(2) · · Score: 1

    ** is very interesting. mplayer **/*.mp3 for example =) This might not be useful in scripts though

    PS. I'm assuming that ** works like it does in zsh because I haven't RTFA

  65. YEAH you tell 'em... by Burz · · Score: 0, Redundant

    Because the CLI ought to be a DRM-friendly environment!

    Then again even Apple is busy removing DRM from iTMS, so perhaps the BSD folk are just wasting their time.

    1. Re:YEAH you tell 'em... by Burz · · Score: 1

      Because the CLI ought to be a DRM-friendly environment!

      Then again even Apple is busy removing DRM from iTMS, so perhaps the BSD folk are just wasting their time.

      There was absolutely nothing redundant about that post, mod-trolls. :)

  66. Re:So? by EddyPearson · · Score: 1

    If by "the kind of person I was referring to", you mean, one of many millions of competent Unix users out there, then I suppose I am.

    Will this major release affect my productivity directly? Probably not, (although I daresay "improvements to the programmable completion functionality" will be a welcome feature) however, to suggest that bash scripting is merely some bygone vestige of a time where people didn't have "serious" languages work with just shows how far outside your comfort zone you stray when actually considering these things.

    Bash is core to almost all the major Linux distributions out there (in the sense that it is the default shell). It is a serious technology indeed, just as relevant today as it ever was. A major release is not only worthy of the Slashdot front page, but I'd be disappointed if I hadn't heard it here first.

    --
    You feel sleepy. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise.
  67. Re:And? by 93+Escort+Wagon · · Score: 2, Funny

    What's the point? It's worthless on my multi-touch screen. Only crusted headed, unbathed, girlfriendless uber geeks need to use the CLI.CLI's are so 1940's Get with the times you gezzers.

    Hey, I am not an "uber"!

    --
    #DeleteChrome
  68. Oh that's easy by jonaskoelker · · Score: 1

    I was really hoping someone would post a picture of a half-rotated Compiz cube with a bash shell running transparently on it.

    Just find any random old youtube video of people showing off Compiz. Superimpose an xterm with alpha=0%, and there's your transparent bash shell ;-)

  69. Re:So? by fm6 · · Score: 1

    You honestly think there are millions of people out there whose primary user interface is a shell command line? You need to get out more!

  70. Re:So? by kitgerrits · · Score: 1

    Like the way Red Hat uses nash?

    --
    "I was in love with a beautiful blonde once, dear. She drove me to drink. It's the one thing I am indebted to her for."
  71. erm... by msimm · · Score: 1

    a Windows or OSX dig would have been nice. ;-)

    --
    Quack, quack.
  72. Re:So? by EddyPearson · · Score: 1

    Primary no, but like it or not, it an absolutely necessary part of any Linux user's skill set.

    Is there a single Linux (or Unix) user without some knowledge of bash? For many, it is almost synonymous with Linux, it has to be one of the most pervasive pieces of software out there.

    --
    You feel sleepy. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise.
  73. Re:So? by NemoinSpace · · Score: 1
    Which one is more compatible with Jun 25 12:20:47 pc1h kernel: lp0 on fire ?

    Should I upgrade or grab another fire extinguisher?

    it's getting kind of smoggy here! /nervously waiting for reply/

  74. Re:So? by lilomar · · Score: 1

    wikipedia says: Debian Almquist shell

    sigh, I was really hoping they had called it the Deade Again SHell

    --
    The creator of this post (Jacob Smith) hereby releases it, and all of his other posts, into the public domain.
  75. Re:So? by turbidostato · · Score: 1

    "... Err, what? Shell scripts are used all the time. Even upstart services are still often written as shell scripts. Really, why all the anti-shell hostility around here?"

    Err... did I say nothing against shell scripts, uh?

    I talked about *Bash* scripts. Init scripts should be standard shell, not Bash, as per the single unix specification. Any init script using Bash should be considered a bug but for very few exceptions.

    Oh! and by the way... *All* "upstart services" must be written as shell scripts, not just "oftenly".

  76. It already is year of the Linux... by mario_grgic · · Score: 1

    and has been for a long time now. It's an OS that caters to the high end of the technical skill bell curve.

    --
    As the island of our knowledge grows, so does the shore of our ignorance.
  77. Re:So? by Anonymous Coward · · Score: 0

    Yeah, but Gentoo bash has funroll loops built-in!

  78. Re:So? by Macka · · Score: 1

    Most serious scripts are (and continue to be) written using /bin/sh. Maybe your definition of serious is something different?

    Yeah right. I've worked at a few places where /bin/sh was the strict standard. And guess what, every one of the "serious" scripts I saw were liberally peppered with invocations of sed & awk to get anything "serious" done, because /bin/sh is so devoid of useful builtins. In all cases the use of awk for example was an unholy mess, and anyway, writing scripts like that breaks the golden rule for writing fast scripts: i.e. stick to using buildins as much as possible to keep the number of context switches down to a minimum.

    If anyone wants to do "serious" scripting, then they should pick the right tool for the job, and /bin/sh just doesn't cut it.
       

  79. Re:So? by LingNoi · · Score: 1

    I know you didn't mean to but could you please not use nabble links. Please try and find the original mailing list rather then those content stealing assholes.

  80. Maybe it's time to switch by nightfire-unique · · Score: 1

    For whatever reason, I've been a diehard tcsh user for the last 15 years. It's clear that bash is the standard, and where all the development effort is going (at least relative to csh/tcsh).

    Sometimes it feels like I'm the only tcsh user left.

    --
    A government is a body of people notably ungoverned - AC
    1. Re:Maybe it's time to switch by seebs · · Score: 1

      If you want to develop scripts, definitely use one of the Bourne derivatives; the POSIX subset's pretty livable.

      For command-line interaction, whatever you're used to is probably fine.

      --
      My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
  81. Re:Seems like a bad acronym by LingNoi · · Score: 0

    No way, GIMP is by far the worse program name.

  82. Re:So? by fm6 · · Score: 1

    Is there a single Linux (or Unix) user without some knowledge of bash?

    So what? Users with "some knowledge" won't ever use these fancy new Bash 4.0 features. They don't even know how to use more basic stuff, like pipes and filters.

  83. Re:So? by mario_grgic · · Score: 1

    If you use vi key bindings (set -o vi), then ESC v will launch vi (or whatever your EDITOR variable is set to) to edit you current command line. This is useful if the command line gets really long. Navigating single long line in VIM (with gj and gk) is much faster.

    --
    As the island of our knowledge grows, so does the shore of our ignorance.
  84. De Facto Bullshit by fm6 · · Score: 2, Interesting

    When did bash become the "de-facto standard"? I work at Sun, which has been in the Unix business for a couple decades. The most common interactive command line here is csh. (Bill Joy being the original head of software probably had something to do with that.) Most software developers here do prefer bash to csh, especially for scripting. But if somebody tried to tell them they couldn't use any other scripting language, they'd probably quit all at once. If you asked them what the de-facto standard was, I think they'd all say Perl. Even the ones that hate Perl.

    Your religiousity about bash may work for you, but it wouldn't for most people. I'm a writer, not a developer, but I do need to write the odd small program now and then. The other day I wrote a 20-line Perl script that pulls a list of names off a web site, looks them up in an LDAP database, and saves retrieved user data in a text file. (The point is to synchronize a web site user access list that I maintain with one that I don't.) I'm sure I could do it as a shell script, but it would be a lot more complicated, and probably a bit less efficient.

    1. Re:De Facto Bullshit by Crimsonjade · · Score: 1

      Most software developers here do prefer bash to csh, especially for scripting.

      Hence, the de-facto standard.

    2. Re:De Facto Bullshit by fm6 · · Score: 1

      Sigh. They reading my post all the way through. It's not that long.

  85. which side....... by Anonymous Coward · · Score: 0

    linux should find some way to do "looping GUI" actions easily.....
    linux is good for "farms" coz it's easy to do "looping" job
    windoz is good for "dumbs" coz it's easy to point-n-click
    so for "dumb farms" u need "looping GUI"....

  86. an ls | sed | sh pipeline by Anonymous Coward · · Score: 0

    Haha, I've done things like the mplayer example as
    ls */ | sed 's/^\1$/mplayer \1*.mp3/' | sh
    This is because I'm a noob that knows very few GNU commands, but enough to be hazardous.

  87. Re:So? by Xtifr · · Score: 1

    On the other hand, on Ubuntu, I only see three "Bourne-Again shell script text executable" files in /etc/init.d. The rest are all (or claim to be) "POSIX shell script text executable". Of course, that really only means that they start with "#!/bin/sh" instead of "#!/bin/bash", but Ubuntu is derived from Debian which has fairly strong policies about not allowing bashisms in /bin/sh scripts.

  88. Re:So? by Xtifr · · Score: 2, Interesting

    Is there a single Linux (or Unix) user without some knowledge of bash?

    Yes, lots and lots. At my house, for example, we have eight Linux users, but only two of them have any knowledge of bash. At my aunt's house, there is one user of Linux, but none with any knowledge of bash. Depending on how far you're willing to stretch the definition, every person with a TiVo could be considered a Linux user, and very few of them are likely to have any knowledge of bash. Etc., etc.

  89. Re:So? by Erikderzweite · · Score: 1

    Baselayout2 uses openrc which is written in C. (damn, it even rhymes!)

  90. Re:So? by cheater512 · · Score: 1

    OpenRC is C, Baselayout 2 is bash.
    They work together.

    Check under /lib64/rc/sh/

  91. Re:So? by Anonymous Coward · · Score: 0

    This thread is giving me a rash.

  92. seems to introduce a number of zsh features by sentientbrendan · · Score: 1

    I believe both recursive globbing "**" and coroutines are zsh features.

    I'm glad they included this. I think it's fair to say that lack of recursive globbing support was pretty annoying in the past. Using a command composed with find composed with xargs was the previous alternative... and pretty over complicated compared to **.

    In the past I'd switched to zsh, but moved back because most shell scripting information online is built around bash. This makes sticking with bash that much easier.

  93. Re:So? by Anonymous Coward · · Score: 0

    Weird, because Debian moving away from bash to dash for exactly the same reasons.
    http://www.nabble.com/Making-init-scripts-use-dash-td4458217.html

    No, it would be "weird" if they moved from bash to python for the same reason.

  94. Re:Seems like a bad acronym by Anonymous Coward · · Score: 0

    Is that the new Zune?

  95. Re:So? by tigersha · · Score: 1

    Have you even seen Monowall? To quote from its website:

    m0n0wall is probably the first UNIX system that has its boot-time configuration done with PHP, rather than the usual shell scripts, and that has the entire system configuration stored in XML format.

    Monowal is actually rather nice.

    --
    The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
  96. Re:So? by Dreadneck · · Score: 2, Funny

    Gentoo uses bash for their init scripts citing reasons of speed.

    Weird, because Debian moving away from bash to dash for exactly the same reasons.

    Like the way Red Hat uses nash?

    Or the way Microsoft uses cash?

    I apologize, but I saw the opening and had to take the shot.

    --
    Power does not corrupt - power attracts the corrupt.
  97. Call me a dreamer... by Anonymous Coward · · Score: 0

    I am still waiting for a standard command line syntax for every command, standard command naming convention for commands, standard config file format in /etc, standard output, object piping... oh well, this just looks like powershell... damn! Is there a project trying to bring sanity to this mess?

  98. Ah, a friend of mine LOVES you by SmallFurryCreature · · Score: 4, Insightful

    He has a garage, fixes cars. He LOVES people that don't think they need to operate their car. Some lovely person puts petrol in the company van, ah christmas come early! Oil light been on since "Oh I just ignore that as the car starts fine with it on", we will eat tonight!

    The simple fact is that we got to know a lot of stuff and if we don't we pay other people a LOT of money for knowing their stuff. 175 euro for 15 minutes work unglogging a toilet because some female doesn't know you can't put femine hygiene products down the toilet.

    50 euro to run a set of automated tools on your PC to clean it, total labor involved, inserting a USB stick, you got to bring the PC in, during quiet hours and pick it up yourself, no warranty.

    My neighbour changed his the nature of his small construction firm, he no longer does projects for clients, he assists DIY'ers with theirs. To translate, he charges a FORTUNE to fix the mess they made and has their free labor to help out with simple but expensive to hire a pro for tasks.

    Everytime somebody like you defends people not having to know the tools they use, somebody somewhere sees dollar signs.

    --

    MMO Quests are like orgasms:

    You may solo them, I prefer them in a group.

    1. Re:Ah, a friend of mine LOVES you by Hurricane78 · · Score: 1

      True. Very true.

      Interestingly, this is true for the human body too.
      How many people do you know, that operate their body how it was meant to be used?
      I bet, not a single one.

      They spend huge sums on health care (usually only symptom treatment), so they can continue to ignore their wrong behavior, of eating trash and not moving.
      The human body is a very impressive machine, that is primarily made for complex thinking and running/hunting for long times. But it runs on a very complex set of resources.
      If there is an imbalance in those resources (usually too much short carbohydrates and saturated fats, not enough of the vital substances), you get into trouble.

      It is pretty strange, that we, as we love to tweak complex systems, and make them run ABNORMALLY FAST*, but we ignore the most advanced machine we have access to: Ourselves.
      How about hacking yourself a bit? Run fastest, think hardest, and use the most cool hacks ever conceived! :D

      In fact, I will start right now. Aaah... the power of self-motivation... ;)
      ___
      * If you know Powerthirst ;)

      --
      Any sufficiently advanced intelligence is indistinguishable from stupidity.
    2. Re:Ah, a friend of mine LOVES you by Kjella · · Score: 1

      Granted, some people are idiots. But I don't want to know all the tools and parts and procedure to change the gearbox. For the most part I rely on a working market where if my auto mechanic was completely ripping me off there'd be other mechanics willing to do it for less. Sure, there's a lot of imperfect information and limited number of workshops to have something fixed but chances are the one I land on isn't wildly inaccurate to the real cost of doing it. Unless I got a particular interest in fixing things myself, the only thing I'd like to know is how to operate them, probably not in the best way but enough to not damage them and get done what I need done.

      If I want to drive from A to B then I just need a route. Not the shortest route, the fastest route, the most fuel-efficient route or whatnot. I don't want to memorize the whole map and make a million dynamic route decisions based on detours and traffic density and whatnot. I just want to know what I need to get my job done, not understand every other possibility of doing it. Same with computers, people want to know how to do tasks, not know all the possible sideroutes of things you could do with a computer. Trouble with the computer is that the messages are a bit like driving without actually seeing the road signs. "Possible rock slides", "Deer crossing", "Sharps turns" yeah could just click past those and probably still do fine. Then there's the "bridge out" sign...

      --
      Live today, because you never know what tomorrow brings
  99. Freedom at a price by Yfrwlf · · Score: 3, Interesting

    "Most of us will probably wait for the distros to test the new version and upgrade gradually, but you always have the option of grabbing the source and compiling it yourself."

    Translation: "Most of us would try it out if only it was easy to do so and we had the freedom to easily install and use Linux software, but we don't, because software installation standards have yet to be worked out and right now it's annoying as hell tracking down the dependencies manually and struggling through the compilation process. Instead, we'll rely on distro companies to give us access to software instead of being able to download and run like Mac and Windows users have the luxury of doing."

    Yeah, I'm sure I'll hear the "if they want to try out BASH then they probably know how to compile already" argument, but a) that doesn't make it any less annoying, just because you like using the command line doesn't mean you hate convenience, and b) I'm speaking generally about the sever lack of Linux binaries in existence, and the complete lack of nice installation packages unless you get lucky and someone targeted your specific version of your specific distro.

    Once Linux application installation becomes a snap, so any Linux users can easily share software, you will see a much greater proliferation of Linux programs out there, torrents etc, because it will actually be useful keeping archives of packages because they won't go obsolete in 6 months. Once users can easily share Linux programs, it will help make Linux adoption sore and Linux users who don't want to or don't know how to compile will finally be free of suckling on distro companies for their software milk.

    --
    Promote true freedom - support standards and interoperability.
    1. Re:Freedom at a price by Chryana · · Score: 1

      One of the main advantages of being on a linux box is that I don't have to either
      - go to every website with some piece of software I use and download it, and install it every new release, or
      - run a dozen different update programs in the background that ask me to download and install a new version every time java or quicktime has a new release, or
      - run tons of outdated software.
      You do have a valid point that apps can be hard to install, but often it is possible to download a precompiled version from the developers' website or even a package that will install just fine on your computer, as long as you run a reasonably popular distribution. However, I think that the ability to keep all my software updated with minimal efforts far outweighs the ability to try new programs as soon as they are released.

  100. Re:So? by berend+botje · · Score: 1

    I'm aware of a not-obscure high-volume website (yes, porn; no, not telling which) running on nothing but shell scripts. No other language needed.

    Not sure why, but the site is very fast and scales exceptionally well. It even does database access (don't know which db, I'm not a developer at that site).

  101. echo test|read a;echo $a # now working? by Gunstick · · Score: 1

    So is bash still the only shell getting pipes wrong.
    In all other shells, the last part of the pipe is in the current process.

    In bash, the first part of a pipe is, which is completely useless. If it's the last one, you can effectively modify variables and use them later.
    e.g.:

    ls | while read a
    do
        myls="$myls $a"
    done
    echo $myls

    ok, it's a silly example but what would you expect happens by just quickly looking at the code. The echo shows the ls? Well not in bash, it just is empty!
    But the bash people still ignore this bug, because in POSIX it is not clear which part of the pipe is in the current process. Well why don't they do it like all the others?

    --
    Atari rules... ermm... ruled.
  102. Ahh, the power of versioning (Re:Backward Comp...) by sowth · · Score: 1

    Just build the binary and install it as /bin/bash-4.0 or bash4, and you can use the new version, while your scripts don't break. If you want to start testing, try running some of your scripts under the new version. When you are more confident, you can symlink /bin/sh to your new bash4.

    Many binaries use this type of protocol: gimp, gcc, and several others. It allows you to use multiple versions at once, if you wish. The default one is just a symbolic link from say gimp to gimp-2.4 -- Simple. Effective. Easy.

  103. Re:So? by idlemachine · · Score: 1

    Really, why all the anti-shell hostility around here?

    Ignorance, basically.

  104. Re:Linux by NightFears · · Score: 1

    man gay

  105. Can't have everything by Wheely · · Score: 1

    Great update.

    For me, standards across all the *nix flavours is key so I probably won't use associated arrays in a shell script. Can't help but like them though.

    Love that we finally have co-processes, hate that the syntax is completely non-standard.

    Great to see bash updated though.

  106. no, it is linux not the users by cinnamon+colbert · · Score: 1

    I did a wubi install of ubuntu on my laptop, and it installed and ran ok
    and...
    incredible - all these volunteers have produced a great OS/desktop that installed nearly flawlessly
    or
    so what - it is the same as windows, so why should I care ?

    which is the problem: if windows is your target, who cares if you are equal or even slighlty better.

  107. Circular generations... by Atmchicago · · Score: 1

    And stay away from any living cells! (think about it...)

    --

    You can lead a horse to water, but you can't make it dissolve.

  108. now we're complaining about vi? by Anonymous Coward · · Score: 0

    Are you specifically referring to the stagnant vi, or the class of vi editors (most notably vim)? If the former, yeah, sure whatever. If the latter, stop flaimbaiting. Just as csh users almost universally use tcsh (which is fine unless you're scripting), vi users almost universally use improved versions of vi like vim or elvis. The scripting argument is moot. You can find vim gurus that completely pwn emacs experts at efficient coding with their editor in the same way that you can find emacs gurus that wreck vim experts. It's pretty even, and there is no clear winner.

    vim and emacs are in a league all their own, and others such as joe, kate, and bbedit aren't too far behind (some landing far closer than others). See Wikipedia's comparison of text editors for detail on what you're missing.

  109. Not exactly true by UberLord · · Score: 1

    Gentoo stable requires bash for baselayout-1
    Gentoo unstable uses /bin/sh for OpenRC

    I know - I wrote OpenRC and maintained baselayout-1 for a long time :)

    For pure startup, busybox sh is the fastest, followed by dash followed by bash.
    busybox is fastest purely because it doesn't fork as much due to the apps builtin. Plus the apps in question generally have much shorter code-paths due to many GNU extensions being stripped.

    I didn't test zsh or pdksh for speed.

    1. Re:Not exactly true by slash.duncan · · Score: 1

      Thanks, Uberlord. I was going to post something similar, but having it straight from the horse's mouth as they say is far better.

      Um, not that I'm calling you a horse, that's just the saying! =;^)

      --
      Duncan
      "Every nonfree program has a lord, a master,
      and if you use the program, he is your master."
      R Stallman
  110. Tell that to the FreeBSD team by Viol8 · · Score: 1

    Its the bloody default shell. I can't stand it - why can't they use bash or just plain bourne shell FFS?

  111. stop it by cromar · · Score: 1

    It's no fun if you get all rational about it. Nobody actually gives a flipping fuck what text editor you use. This argument is ritual by now and here for everyone's continued enjoyment.

  112. Can someone tell me this? by swordgeek · · Score: 1

    When invoked as sh (i.e. in sh-compatibility mode), how does the following display?

    $ echo "hello\n"

    --

    "People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
  113. WHAAAAAAAT!?!! by Crazy+Taco · · Score: 1

    The idea is that people should never have to be ready for (nor aware of) any OS at all.

    WHAT?!! If they aren't aware of their OS and its inner workings, then how are they going to edit their config files? It's not a true computer, or a true operating system, if you don't have to edit config files from the command line! This whole idea makes no sense to me!

    --
    Beware of bugs in the above code; I have only proved it correct, not tried it.
  114. BSD has zsh by Khopesh · · Score: 1

    Bash is GPL, which is not compatible with the BSD license. The standard response is to use zsh, which is more powerful than bash, insanely featureful, and BSD-licensed. I'm not a BSD user, but zsh is now my shell of choice. These days, the differences are so minor that it doesn't matter. The only big-deal feature in zsh but not bash that I can think of is RPROMPT and maybe the better completion. (See the screenshot of my power-tweaked zsh shell.)

    I was under the impression the BSDs used zsh as the default shell. Maybe that's NetBSD?

    --
    Use my userscript to add story images to Slashdot. There's no going back.
  115. Re:Linux by Anonymous Coward · · Score: 0

    Not bad for a first attempt, but you need to start a bit more gently to draw them in before you lay in with the hard stuff.

  116. pysh: Python as a shell by Requiem18th · · Score: 1

    $ sudo apt-get install ipython
    $ ipython -p pysh

      You can make an alias or a (cue drum roll) shell script with that last command. The nice thing about pysh is that it has prevented me from learning to do anything complex in bash. I'm a slacker.

    --
    But... the future refused to change.
    1. Re:pysh: Python as a shell by Anonymous Coward · · Score: 0

      what's the advantage of this versus say
      starting python interactively ( besides filename
      expension or something like that ) ?

    2. Re:pysh: Python as a shell by Requiem18th · · Score: 1

      Off the top of my head:
        Current path displayed in prompt
        Navigate with cd, ls, pushd and company
        Lines that look like a shell lines are interpreted as shell lines
        You can force shell execution with "!" and even store its return value into variables, some commands even have special output when used this way for instance
      >>> foo = !ls
        Makes foo a list of strings with the current dir files.
        You can pass python vars as strings to shell commands using $ syntax

        for instance you can use urllib and BeautifulSoup to load and parse a web page, once you have the appropiate links in a variable named "urls" you can do
      >>> for url in urls:
              !wget $url

        Is that enough?

      --
      But... the future refused to change.
  117. Re:So? by chthonicdaemon · · Score: 1

    I get worried when a lowish UID person on slashdot is so blase about the commandline. I own a mac and I do most of the file stuff in the command line. On my work machine, I don't even have a GUI file browser installed. When you are handling lots of files, nothing else really makes sense, unless you are doing something common enough to have been GUIfied, like MP3 or photo management.

    I have tried many times to use file managers, but I always feel like my hands are chopped off when I try to do even basic stuff like 'move all the PDFs in directory A to directory B', or 'find all the files in my Documents folder that are newer than File A'. Probably the only place where a graphical interface contributes is if the files have a reasonable graphical interpretation and are not named consistently, like a random dump of images from someone's flash disk.

    --
    Languages aren't inherently fast -- implementations are efficient
  118. Re:So? by fm6 · · Score: 1

    It's even worse than you think! Not only do I have a low UID, but I've actually been using computers for a really really long time. I started in 1971 (PDP-11 running RSTS), didn't even see a GUI machine until 1983 (when the company I was working for bought a Mac to do competitive analysis on it), and didn't start using one day-to-day until 1990 (when Windows 3.0 came out). Even then, it was some years before Windows file managers progressed enough to that I could use them for most complicated operations.

    That's over a decade when I used various command lines (mostly csh until I became a MS-DOS person, when I relied on something called 4DOS) because there was no alternative. Than some years before the alternatives got good enough so that I could rely on them most of the time. I got pretty good at hacking shell scripts and aliases.

    I still am, though certainly not in your league. Nowadays I go back and forth between Solaris and Windows, and on the Solaris side there's still a lot of things that are easier to do in the command line.

    So, with all this command line experience, why am I a GUI apostate? Because it suits the way I think better. Visual metaphors means that I don't have to devote brain cells to remembering and elaborating the idiom I need. Visual feedback tells me immediately whether the idiom I used did what I thought it did.

    You see these mechanisms as crutches and that interfere with your ability to work efficiently, and prefer more powerful tools. If that works for you fine. Despite the way most people read my original post, I am not saying that only idiots use the command line. Though I strongly suspect that a powerful command line appeals to you more for the intellectual stimulation and pleasure you get from using it, rather than any increase in your efficiency.

  119. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  120. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  121. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  122. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  123. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion