Bug 75668

Summary:	4.11-RC1: /etc/shells missing /usr/local/bin/bash
Product:	Base System	Reporter:	Randy Pratt <rpratt1950>
Component:	conf	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	Unspecified
Hardware:	Any
OS:	Any

Description Randy Pratt 2004-12-30 19:20:25 UTC


In a fresh install of 4.11-RC1  /etc/shells contains "/usr/local/bin/bash2" instead of the familar "/usr/local/bin/bash", consequently sysinstall and chsh do not see "/usr/local/bin/bash" as a valid shell.

This is different than the behavior in the past.

Fix: 

Change "/usr/local/bin/bash2" to "/usr/local/bin/bash" or additionally add "/usr/local/bin/bash" to /etc/shells.
How-To-Repeat: 

Try to set a user's shell to bash with sysinstall or chsh.

Comment 1 Ceri Davies 2004-12-31 15:48:00 UTC

On Thu, Dec 30, 2004 at 02:12:29PM -0500, Randy Pratt wrote:
> 
> In a fresh install of 4.11-RC1  /etc/shells contains "/usr/local/bin/bash2"
> instead of the familar "/usr/local/bin/bash", consequently sysinstall and
> chsh do not see "/usr/local/bin/bash" as a valid shell.

I believe that this is a feature of the bash2 port - if you want
/usr/local/bin/bash in /etc/shells then you have to install shells/bash
or shells/bash1.

Ceri
-- 
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former.			  -- Einstein (attrib.)

Comment 2 Giorgos Keramidas freebsd_committer

2005-02-23 18:18:45 UTC

State Changed
From-To: open->closed

The bash ports take care of updating /etc/shells at install 
and deinstall time.  Something else is wrong with the setup 
of the machine that exhibited the problem.

Comment 3 Daniel Gerzo 2005-02-23 22:58:11 UTC

Hello freebsd-gnats-submit,

  since bash isn't part of the base system, it seems like a bash
  port/package issue and this PR should be closed, shouldn't it ?

-- 
Best regards

+----------==/\/\==----------+             FreeBSD
|  DanGer <danger@rulez.sk>  |     (__)    The
| DanGer@IRCnet ICQ261701668 |  \\\'',)    Power
|   http://danger.rulez.sk   |    \/  \ ^  To
+----------==\/\/==----------+    .\._/_)  Serve

[ Clinton: "Well, how're we gonna pull the wool over their eyes today?" ]

Comment 4 Giorgos Keramidas 2005-02-25 10:59:11 UTC

On 2005-02-23 23:08, Randy Pratt <rpratt1950@earthlink.net> wrote:
>On Wed, 23 Feb 2005 18:20:07 GMT
>Giorgos Keramidas <keramida@FreeBSD.org> wrote:
>> State-Changed-From-To: open->closed
>> State-Changed-By: keramida
>> State-Changed-When: Wed Feb 23 18:18:45 GMT 2005
>> State-Changed-Why:
>> The bash ports take care of updating /etc/shells at install
>> and deinstall time.  Something else is wrong with the setup
>> of the machine that exhibited the problem.
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=75668
>
> The problem exhibits itself during the initial installation of
> the OS.  Its also dependent on which bash is included on the
> cdrom media.  Some have bash and some have bash2.  That is what
> seems to determine what goes in /etc/shells.
>
> Its not readily apparent of what you need to enter for a user's
> bash shell when creating a new user at installation with sysinstall.
> If bash2 is what is included in the packages, then entering
> "/usr/local/bin/bash" generates an error.
>
> In the Handbook, Figure 2-62. Add User Information, shows
> /usr/local/bin/bash as the shell when bash2 was previously
> added.  In the past, this did work since both bash and bash2
> were in the /etc/shells.
>
> The 4.11-RELEASE is long past so it doesn't matter for that but
> I think some small disconnect is there.

I think we have to update the Handbook.  I just deinstalled bash2 and
installed it as a package (built locally, but that shouldn't matter).
The package install/deinstall process correctly updates /etc/shells.

This means that what seems like a mistake in the Handbook, is very
probably just that: a bug of the Handbook (which should certainly
be fixed).