Why not use bash by default?

Status
Not open for further replies.
Bash has many bugs, it is overloaded, Bash would menace the stability of FreeBSD, prob. of license, ... and so and so on, and not necessary at all.

FreeBSD has already many too much things by default !!

It would be like as worst as having a SystemD ;)
 
Bash() is superior to sh() in most respects, but people don't realize it because they don't know what it's capable of. Just like the people that think vi() is anywhere equal to vim(), probably because they don't know about Vimscript.

Here are some of the commands for manipulating the history that are exclusive to Bash():
Code:
   Commands for Manipulating the History
     beginning-of-history (M-<)
              Move to the first line in the history.
       end-of-history (M->)
              Move  to  the end of the input history, i.e., the line currently
              being entered.
       reverse-search-history (C-r)
              Search backward starting at the current  line  and  moving  `up'
              through  the  history  as  necessary.   This  is  an incremental
              search.
       forward-search-history (C-s)
              Search forward starting at the current line  and  moving  `down'
              through  the  history  as  necessary.   This  is  an incremental
              search.
       non-incremental-reverse-search-history (M-p)
              Search backward through the history starting at the current line
              using  a  non-incremental  search  for  a string supplied by the
              user.
       non-incremental-forward-search-history (M-n)
              Search forward  through  the  history  using  a  non-incremental
              search for a string supplied by the user.
...
      yank-nth-arg (M-C-y)
              Insert  the  first argument to the previous command (usually the
              second word on the previous line) at point.  With an argument n,
              insert  the nth word from the previous command (the words in the
              previous command  begin  with  word  0).   A  negative  argument
              inserts the nth word from the end of the previous command.  Once
              the argument n is computed, the argument is extracted as if  the
              "!n" history expansion had been specified.
       yank-last-arg (M-., M-_)
              Insert  the last argument to the previous command (the last word
              of the previous history entry).  With a numeric argument, behave
              exactly  like  yank-nth-arg.   Successive calls to yank-last-arg
              move back through the history list, inserting the last word  (or
              the  word  specified  by the argument to the first call) of each
              line in turn.  Any numeric argument supplied to these successive
              calls  determines  the direction to move through the history.  A
              negative argument switches the  direction  through  the  history
              (back or forward).  The history expansion facilities are used to
              extract the last word, as if the "!$" history expansion had been
              specified.
       shell-expand-line (M-C-e)
              Expand the line as the shell does.  This performs alias and his-
              tory expansion as well as all of the shell word expansions.  See
              HISTORY  EXPANSION below for a description of history expansion.
       history-expand-line (M-^)
              Perform history expansion on  the  current  line.   See  HISTORY
              EXPANSION below for a description of history expansion.
...
      insert-last-argument (M-., M-_)
              A synonym for yank-last-arg.
       operate-and-get-next (C-o)
              Accept the current line for execution and fetch  the  next  line
              relative  to the current line from the history for editing.  Any
              argument is ignored.
       edit-and-execute-command (C-xC-e)
              Invoke an editor on the current command line,  and  execute  the
              result  as  shell  commands.   Bash  attempts to invoke $VISUAL,
              $EDITOR, and emacs as the editor, in that order.
...
I use those on a daily bases when administering *nix systems. Can you do the job without them? Of course. But you can also eat soup with a fork. I chuckle every time I see someone leaning on their left- or right-arrow keys on the command line when making edits.

My favorite though is its ability to do history expansion:
Code:
HISTORY EXPANSION
       The shell supports a history expansion feature that is similar  to  the
       history  expansion in csh.
...
  Event Designators
       An event designator is a reference to a command line entry in the  his-
       tory  list.   Unless  the reference is absolute, events are relative to
       the current position in the history list.

       !      Start a history substitution, except when followed by  a  blank,
              newline,  carriage return, = or ( (when the extglob shell option
              is enabled using the shopt builtin).
       !n     Refer to command line n.
       !-n    Refer to the current command minus n.
       !!     Refer to the previous command.  This is a synonym for `!-1'.
       !string
              Refer to the most recent command preceding the current  position
              in the history list starting with string.
       !?string[?]
              Refer  to the most recent command preceding the current position
              in the history list containing string.  The trailing  ?  may  be
              omitted if string is followed immediately by a newline.
       ^string1^string2^
              Quick  substitution.   Repeat  the  previous  command, replacing
              string1 with string2.  Equivalent  to  ``!!:s/string1/string2/''
              (see Modifiers below).
       !#     The entire command line typed so far.

   Word Designators
       Word  designators are used to select desired words from the event.  A :
       separates the event specification from the word designator.  It may  be
       omitted  if  the word designator begins with a ^, $, *, -, or %.  Words
       are numbered from the beginning of the line, with the first word  being
       denoted  by  0  (zero).  Words are inserted into the current line sepa-
       rated by single spaces.

       0 (zero)
              The zeroth word.  For the shell, this is the command word.
       n      The nth word.
       ^      The first argument.  That is, word 1.
       $      The last word.  This is usually  the  last  argument,  but  will
              expand to the zeroth word if there is only one word in the line.
       %      The word matched by the most recent `?string?' search.
       x-y    A range of words; `-y' abbreviates `0-y'.
       *      All of the words but the zeroth.  This is a synonym  for  `1-$'.
              It  is  not  an  error to use * if there is just one word in the
              event; the empty string is returned in that case.
       x*     Abbreviates x-$.
       x-     Abbreviates x-$ like x*, but omits the last word.
...
It's one of those things that if you don't know it exists, you don't miss it. But once you've used it, you get pissed off whenever you're stuck on a system that only has sh().
 
Bash() is superior to sh() in most respects, but people don't realize it because they don't know what it's capable of. Just like the people that think vi() is anywhere equal to vim(), probably because they don't know about Vimscript.

Here are some of the commands for manipulating the history that are exclusive to Bash():
Code:
   Commands for Manipulating the History
     beginning-of-history (M-<)
              Move to the first line in the history.
       end-of-history (M->)
              Move  to  the end of the input history, i.e., the line currently
              being entered.
       reverse-search-history (C-r)
              Search backward starting at the current  line  and  moving  `up'
              through  the  history  as  necessary.   This  is  an incremental
              search.
       forward-search-history (C-s)
              Search forward starting at the current line  and  moving  `down'
              through  the  history  as  necessary.   This  is  an incremental
              search.
       non-incremental-reverse-search-history (M-p)
              Search backward through the history starting at the current line
              using  a  non-incremental  search  for  a string supplied by the
              user.
       non-incremental-forward-search-history (M-n)
              Search forward  through  the  history  using  a  non-incremental
              search for a string supplied by the user.
...
      yank-nth-arg (M-C-y)
              Insert  the  first argument to the previous command (usually the
              second word on the previous line) at point.  With an argument n,
              insert  the nth word from the previous command (the words in the
              previous command  begin  with  word  0).   A  negative  argument
              inserts the nth word from the end of the previous command.  Once
              the argument n is computed, the argument is extracted as if  the
              "!n" history expansion had been specified.
       yank-last-arg (M-., M-_)
              Insert  the last argument to the previous command (the last word
              of the previous history entry).  With a numeric argument, behave
              exactly  like  yank-nth-arg.   Successive calls to yank-last-arg
              move back through the history list, inserting the last word  (or
              the  word  specified  by the argument to the first call) of each
              line in turn.  Any numeric argument supplied to these successive
              calls  determines  the direction to move through the history.  A
              negative argument switches the  direction  through  the  history
              (back or forward).  The history expansion facilities are used to
              extract the last word, as if the "!$" history expansion had been
              specified.
       shell-expand-line (M-C-e)
              Expand the line as the shell does.  This performs alias and his-
              tory expansion as well as all of the shell word expansions.  See
              HISTORY  EXPANSION below for a description of history expansion.
       history-expand-line (M-^)
              Perform history expansion on  the  current  line.   See  HISTORY
              EXPANSION below for a description of history expansion.
...
      insert-last-argument (M-., M-_)
              A synonym for yank-last-arg.
       operate-and-get-next (C-o)
              Accept the current line for execution and fetch  the  next  line
              relative  to the current line from the history for editing.  Any
              argument is ignored.
       edit-and-execute-command (C-xC-e)
              Invoke an editor on the current command line,  and  execute  the
              result  as  shell  commands.   Bash  attempts to invoke $VISUAL,
              $EDITOR, and emacs as the editor, in that order.
...
I use those on a daily bases when administering *nix systems. Can you do the job without them? Of course. But you can also eat soup with a fork. I chuckle every time I see someone leaning on their left- or right-arrow keys on the command line when making edits.

My favorite though is its ability to do history expansion:
Code:
HISTORY EXPANSION
       The shell supports a history expansion feature that is similar  to  the
       history  expansion in csh.
...
  Event Designators
       An event designator is a reference to a command line entry in the  his-
       tory  list.   Unless  the reference is absolute, events are relative to
       the current position in the history list.

       !      Start a history substitution, except when followed by  a  blank,
              newline,  carriage return, = or ( (when the extglob shell option
              is enabled using the shopt builtin).
       !n     Refer to command line n.
       !-n    Refer to the current command minus n.
       !!     Refer to the previous command.  This is a synonym for `!-1'.
       !string
              Refer to the most recent command preceding the current  position
              in the history list starting with string.
       !?string[?]
              Refer  to the most recent command preceding the current position
              in the history list containing string.  The trailing  ?  may  be
              omitted if string is followed immediately by a newline.
       ^string1^string2^
              Quick  substitution.   Repeat  the  previous  command, replacing
              string1 with string2.  Equivalent  to  ``!!:s/string1/string2/''
              (see Modifiers below).
       !#     The entire command line typed so far.

   Word Designators
       Word  designators are used to select desired words from the event.  A :
       separates the event specification from the word designator.  It may  be
       omitted  if  the word designator begins with a ^, $, *, -, or %.  Words
       are numbered from the beginning of the line, with the first word  being
       denoted  by  0  (zero).  Words are inserted into the current line sepa-
       rated by single spaces.

       0 (zero)
              The zeroth word.  For the shell, this is the command word.
       n      The nth word.
       ^      The first argument.  That is, word 1.
       $      The last word.  This is usually  the  last  argument,  but  will
              expand to the zeroth word if there is only one word in the line.
       %      The word matched by the most recent `?string?' search.
       x-y    A range of words; `-y' abbreviates `0-y'.
       *      All of the words but the zeroth.  This is a synonym  for  `1-$'.
              It  is  not  an  error to use * if there is just one word in the
              event; the empty string is returned in that case.
       x*     Abbreviates x-$.
       x-     Abbreviates x-$ like x*, but omits the last word.
...
It's one of those things that if you don't know it exists, you don't miss it. But once you've used it, you get pissed off whenever you're stuck on a system that only has sh().

It is probably much better to use vi, if you find it ok, than vim.
Elvis to vi, and so on.
If something works and is fine for you like this. nano is also fine and easy to compile and to port.

Sometimes, it's some overkill to have thousand features that we do not need, because it takes memory and resource.

Some users need them for a shell, so they can still try to compile bash from source or run pkg install bash, and make bash default.
 
Also, a note of overly configurable things: people tend to massively personalise them.

I’ve worked on lots of boxen which I’m not allowed to configure (many customer sites where I don’t get a personal user account).
Having an overly configured shell or editor would have (and has in some cases) slowed me down and would me up on machines where my configurations don’t exist, and therefore my muscle-memory is useless.
 
A number of these are available in shells/zsh, shells/ksh93, and tcsh(). So we have a number of ther shells which are more permissibly licensed.

Some people care about this, others don’t.

Yeah, no doubt, the licensing issue isn't trivial and I'm not trying to minimize it. I'm just pointing out the feature-set differences between Bash() and sh() that I think make Bash() superior.

My issue with the other shells you listed is that some of their default settings are annoying to me and they feel too hand-holdy. Is it shells/ksh93 that sublists filenames instead of auto-completing words first? That really bugged me.
 
It is probably much better to use vi, if you find it ok, than vim.
Elvis to vi, and so on.
If something works and is fine for you like this. nano is also fine and easy to compile and to port.

Sometimes, it's some overkill to have thousand features that we do not need, because it takes memory and resource.

Some users need them for a shell, so they can still try to compile bash from source or run pkg install bash, and make bash default.

I like vi(), just not as much as vim(). Some things about it are just annoying: I don't like vi()'s rub-out settings at all, and it's one of the first settings changes I add to my .vimrc files.

The "overkill" concern is nonsensical to me though. Having access to better tools makes for better administration. Some people are scared of complexity or too many options though I'm sure. I know a guy that still doesn't even know how to use dd to delete a line in vi() or vim(). He simply goes to the end of the line, hits a, then deletes to the start of the line. He hates too many options, too. :D
 
Indeed, and now I’ve gotten used to tcsh() and configured my shells/zsh to be a bit more like it, I find shells/bash’s defaults to be kinda annoying.
Horses for courses and all that

You've been corrupted, haha. Bash() isn't perfect, but you don't lose any command line administration power by using it over the others you've listed. And when there's something niggling about the way it behaves, you can make .bashrc changes to it, thereby changing your course to match your horse. ;)
 
Also, a note of overly configurable things: people tend to massively personalise them.

I’ve worked on lots of boxen which I’m not allowed to configure (many customer sites where I don’t get a personal user account).
Having an overly configured shell or editor would have (and has in some cases) slowed me down and would me up on machines where my configurations don’t exist, and therefore my muscle-memory is useless.

I've ran into similar situations, but that's easily addressable by running bash --noprofile --norc and vim --norc. Then, it's merely a matter of memorizing your favorite vim() settings and blasting them at the command line: :set nu hls wmnu wim=longest,list, etc. Takes less than 10 seconds, and allows you to be more efficient while still having access to the extensive list of vim() commands that vi() lacks.
 
1. Because bash is GPL licensed and it is impossible to use it in FreeBSD base system.

2. Because other shells are also available preinstalled: sh for scripting and tcsh for interactive usage.

3. IMO zsh is much better applicant for default FreeBSD shell.
               a. Because it uses MIT-like license, that should be compatible with BSD license, and
               b. because it is much more usable than bash as an interactive shell, and even better then tcsh
               (for scripting we still are able to use regular bourne shell /bin/sh).
               c. Because zsh got bash emulation, just create zsh to bash symlink and use it to start bash scripts.
 
Last edited by a moderator:
To summarize, if you've been in IT professionally, in other words, to earn a living, you best embrace whatever it is whether you like it or not or just go private practice - of course you have a choice and can work it where ever you want, but for me - it's knowing Windows up to v10, Mac v(insert mountain), Linux (who cares!), Solaris (10/11), AIX (yes it's still around) and even BSD that keeps food on the plates for my family. If I have to use sh or bash or ksh or tcsh or whatever, it doesn't matter. The important thing is to know how to use it and if it's not there, in this case bash for FreeBSD, then just install the port and use it. I don't see any sense in demeaning anyone who thinks their shell is better than some other shell. Microsoft adding Bash to Windows 10 ought to be a sign of what's to come. Look at the statistics. Hate wont get you anywhere.
 
I don't hate anyone for using it. If you like it, use it. I have another shell preference, and I just install it.

It just perplexes me, because it's one of the first things I've learned about in FreeBSD (probably before I ever installed and used it), and I always come across why it's not in base. I don't think anyone is stupid for not knowing that; I don't understand how someone can go so long, without knowing it. It's like someone smart, who didn't do their homework/research for a long time. Newcomers, however, shouldn't be expected to know it. I'm going to leave it at that.

The issue should be, what's the easiest way to install the shell you like, as if it's in your own customized FreeBSD base, during/after your compile or freebsd-update.
 
I don't understand why a lot is on that list... svg, pdf, SQL, svn, XML (it carries more overhead than it should, and gets complex easy, but still structured), XMPP (probably bc it's XML based), it says no httpd is best, FreeBSD and NetBSD, Apache license and MPL.

The lower down section explains.
Note: At the moment a detailed rationale
is not provided for most of this, so figuring out
why some things are considered more or less
harmful than others is left as an exercise for
the reader. Here is a hint: complexity is the
bane of all software, simplicity is the most
important quality.
 
Saw this list some time ago... Title of page "All software sucks" says it all.

My advice to the author — is not to use any computer at all, it will be most "harmless" for him.
Author is dead apparently: uriel
but my theory is he wanted to get away from it all and faked his death.
 
... and also increases the vulnerability attack surface.

Most coders do not care about it.

besides, .... aren't you hearing this from Win developers?
Java is highly secured !!!
C# is the power in the hands with a high-level of security.
 
Status
Not open for further replies.
Back
Top