[gentoo-dev] RFC: enewuser should force updates to shell and home

[gentoo-dev] RFC: enewuser should force updates to shell and home

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hey all - I'd like to propose that enewuser forces updates to a user's
home dir and shell whenever it is called, so that if this changes with
new versions of an ebuild it is dealt with automatically rather than
having to modify them in pkg_postinst/pkg_setup directly.

Here's my proposed patch to user.eclass -- please note that I can't
conform the syntax for the darwin ('dscl') calls as I don't have
access and my googling did not provide an exact-match in terms of
usage.  The rest i'm highly confident will work based on the manpages
I was able to find.  If anyone has these platforms and can test/update
the calls, I would appreciate it.


- --- user.eclass 2011-12-19 14:38:34.000000000 -0500
+++ user.eclass.forcehomedir    2012-06-13 11:54:26.000000000 -0400
@@ -230,24 +230,39 @@
                for g in "${egroups_arr[@]}" ; do
                        dscl . merge "/groups/${g}" users "${euser}"
                done
+               ### force updates of some user properties
+               dscl . change "/users/${euser}" home "${ehome}"
+               dscl . change "/users/${euser}" shell "${eshell}"
                ;;

        *-freebsd*|*-dragonfly*)
                pw useradd "${euser}" "${opts[@]}" || die
+               ### force updates of some user properties
+               pw usermod "${euser}" -d "${ehome}" || die
+               pw usermod "${euser}" -s "${eshell}" || die
                ;;

        *-netbsd*)
                useradd "${opts[@]}" "${euser}" || die
+               ### force updates of some user properties
+               usermod -d "${ehome}" "${euser}" || die
+               usermod -s "${eshell}" "${euser}" || die
                ;;

        *-openbsd*)
                # all ops the same, except the -g vs -g/-G ...
                useradd -u ${euid} -s "${eshell}" \
                        -d "${ehome}" -g "${egroups}" "${euser}" || die
+               ### force updates of some user properties
+               usermod -d "${ehome}" "${euser}" || die
+               usermod -s "${eshell}" "${euser}" || die
                ;;

        *)
                useradd -r "${opts[@]}" "${euser}" || die
+               ### force updates of some user properties
+               usermod -d "${ehome}" "${euser}" || die
+               usermod -s "${eshell}" "${euser}" || die
                ;;
        esac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/YuRAACgkQ2ugaI38ACPCCxgD/TUhHRThNOHOGoR04CwRwx+Nt
oEJy0MdknD0KDm/uT5oA/AiYZ9fDthJEmPyOgFra+BnWqLCkexvqz+K5SaoS1Pyw
=+xJb
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 348 bytes --]

On Wed, 13 Jun 2012 12:00:16 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> +               ### force updates of some user properties
> +               usermod -d "${ehome}" "${euser}" || die
> +               usermod -s "${eshell}" "${euser}" || die

I think usermod can handle multiple arguments.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/06/12 01:19 PM, Michał Górny wrote:
> On Wed, 13 Jun 2012 12:00:16 -0400 Ian Stakenvicius 
> <axs@gentoo.org> wrote:
> 
>> +               ### force updates of some user properties + 
>> usermod -d "${ehome}" "${euser}" || die +               usermod 
>> -s "${eshell}" "${euser}" || die
> 
> I think usermod can handle multiple arguments.
> 

It can, but I figured it would be easier to debug if something failed,
if each modification was on the same line.  Easy to modify it to be a
one-liner, however (and iirc all but possibly dscl can do this in a
single call)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/YzAsACgkQ2ugaI38ACPAz/AD8DI/5ZynrT/+0rDrgNGPM06l9
dUk/4JSiXKZuxxn7H4oBAL4eHwrPQXXrJWfYDY61QorFqhmVkl5oJdxS4is5WkQQ
=YoDC
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

On 13-06-2012 12:00:16 -0400, Ian Stakenvicius wrote:
> Hey all - I'd like to propose that enewuser forces updates to a user's
> home dir and shell whenever it is called, so that if this changes with
> new versions of an ebuild it is dealt with automatically rather than
> having to modify them in pkg_postinst/pkg_setup directly.

What if some admin purposely changed home or shell for a system account?
Would be quite annoying if every update would reset that, wouldn't it?


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Mike Gilbert]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

On 6/13/2012 12:00 PM, Ian Stakenvicius wrote:
> Hey all - I'd like to propose that enewuser forces updates to a user's
> home dir and shell whenever it is called, so that if this changes with
> new versions of an ebuild it is dealt with automatically rather than
> having to modify them in pkg_postinst/pkg_setup directly.
> 

Can you give an example of a case where modifying the home directory
and/or shell is necessary? I don't really understand how this is useful.

Also, grobian raised a good point in that the sysadmin may have changed
it manually. It might be better to ewarn and make the user deal with it.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Samuli Suominen]

On 06/13/2012 09:18 PM, Mike Gilbert wrote:
> On 6/13/2012 12:00 PM, Ian Stakenvicius wrote:
>> Hey all - I'd like to propose that enewuser forces updates to a user's
>> home dir and shell whenever it is called, so that if this changes with
>> new versions of an ebuild it is dealt with automatically rather than
>> having to modify them in pkg_postinst/pkg_setup directly.
>>
>
> Can you give an example of a case where modifying the home directory
> and/or shell is necessary? I don't really understand how this is useful.

package-1.2.3.ebuild creates user foobard with group foobard and sets 
home to /dev/null

bug gets filed against package-1.2.3.ebuild that foobard needs a home or 
it won't execute itself, and the maintainer changes the home to be 
/var/lib/foobard in package-1.2.3-r1.ebuild

no change happens to passwd and the package continues to fail to run at all

like http://bugs.gentoo.org/420269

sed -i -e '/^foobard/s:/dev/null:/var/lib/foobard' "${ROOT}"/etc/passwd 
in pkg_postinst() doesn't seem very nice solution :/

>
> Also, grobian raised a good point in that the sysadmin may have changed
> it manually. It might be better to ewarn and make the user deal with it.
>

i'd prefer argument to force the update, when the problem hits something 
that 99,98% of users have installed, like sys-auth/polkit, an ewarn is 
not adequate

- Samuli

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/06/12 02:18 PM, Mike Gilbert wrote:
> On 6/13/2012 12:00 PM, Ian Stakenvicius wrote:
>> Hey all - I'd like to propose that enewuser forces updates to a
>> user's home dir and shell whenever it is called, so that if this
>> changes with new versions of an ebuild it is dealt with
>> automatically rather than having to modify them in
>> pkg_postinst/pkg_setup directly.
>> 
> 
> Can you give an example of a case where modifying the home
> directory and/or shell is necessary? I don't really understand how
> this is useful.
> 
> Also, grobian raised a good point in that the sysadmin may have
> changed it manually. It might be better to ewarn and make the user
> deal with it.
> 

The best example at this moment is for a polkit update.  ssuominen can
give you the details.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/Y23oACgkQ2ugaI38ACPAnTAEAms2KIHwFJwa+fzyXKmnAL/UL
vAcMqAwwp2+A05NUWisA/i6JF4zAB+AVE7nrSDEUCH0DZcq84MBOBshfUlQ1xidD
=MrnI
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/06/12 02:09 PM, Fabian Groffen wrote:
> On 13-06-2012 12:00:16 -0400, Ian Stakenvicius wrote:
>> Hey all - I'd like to propose that enewuser forces updates to a
>> user's home dir and shell whenever it is called, so that if this
>> changes with new versions of an ebuild it is dealt with
>> automatically rather than having to modify them in
>> pkg_postinst/pkg_setup directly.
> 
> What if some admin purposely changed home or shell for a system
> account? Would be quite annoying if every update would reset that,
> wouldn't it?
> 
> 


I considered this case, and that it might be more appropriate to
duplicate 'enewuser' into a new call 'eforceuser' (or similar) which
could be used instead of 'enewuser' in cases when the currently
provided user settings should be forced.

I decided against this as it seems also to make sense that users
created by portage should be controlled by portage.

I suppose probably the best means of handling this would be to somehow
detect whether or not the current user settings are default and only
apply the updates if they are; however a means of doing that (which
would be transparent to the ebuild) is somewhat beyond my knowledge
and abilities.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/Y3LYACgkQ2ugaI38ACPCKKwEAsA2kiUEj2Cz5DyuKzlVUvqlq
9N7TH6cEUN7ahL6IIgoA/iiJRJ065vQguz5PmitWVugycdNhm/DCyGcL8j0abcgA
=zd5h
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/06/12 01:21 PM, Ian Stakenvicius wrote:
> On 13/06/12 01:19 PM, Michał Górny wrote:
>> On Wed, 13 Jun 2012 12:00:16 -0400 Ian Stakenvicius 
>> <axs@gentoo.org> wrote:
> 
>>> +               ### force updates of some user properties + 
>>> usermod -d "${ehome}" "${euser}" || die +               usermod
>>>  -s "${eshell}" "${euser}" || die
> 
>> I think usermod can handle multiple arguments.
> 
> 
> It can, but I figured it would be easier to debug if something
> failed, if each modification was on the same line.  Easy to modify
> it to be a one-liner, however (and iirc all but possibly dscl can
> do this in a single call)
> 
> 
> 

As a follow-up to this, I believe it may be possible that my
suggestion is incorrectly coded when considering cases where shell and
home are not specified.  IE, the updates should be called
individually, and should only be called if their respective variable
($ehome, $eshell) is actually set.

I will post an update after some testing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/Y37gACgkQ2ugaI38ACPB+RgD/a4qmpDYsTDCsgvsFmBSMnS9h
CWID5XVVGTPduEcqKeQA/jvpFyDuEd4zh5pSe/fPinq7xLw5lufy+rXq8nxcRsJm
=UofV
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/06/12 02:45 PM, Ian Stakenvicius wrote:
> On 13/06/12 01:21 PM, Ian Stakenvicius wrote:
>> On 13/06/12 01:19 PM, Michał Górny wrote:
>>> On Wed, 13 Jun 2012 12:00:16 -0400 Ian Stakenvicius 
>>> <axs@gentoo.org> wrote:
> 
>>>> +               ### force updates of some user properties + 
>>>> usermod -d "${ehome}" "${euser}" || die +
>>>> usermod -s "${eshell}" "${euser}" || die
> 
>>> I think usermod can handle multiple arguments.
> 
> 
>> It can, but I figured it would be easier to debug if something 
>> failed, if each modification was on the same line.  Easy to
>> modify it to be a one-liner, however (and iirc all but possibly
>> dscl can do this in a single call)
> 
> 
> 
> 
> As a follow-up to this, I believe it may be possible that my 
> suggestion is incorrectly coded when considering cases where shell
> and home are not specified.  IE, the updates should be called 
> individually, and should only be called if their respective
> variable ($ehome, $eshell) is actually set.
> 
> I will post an update after some testing.

Oh, and the code also doesn't do anything as if the user exists
enewuser still returns before any processing is done.  :)


> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/Y4DkACgkQ2ugaI38ACPDe2QD7B+MeuP7MYzShbmaHMBxxQzMu
yerItXd85EU9rKCDHa8A/R3CAgN2sGJIR+LWPjmaegj5UTHToPK1OcKPMmU7JQcx
=vb7t
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Mike Gilbert]

[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]

On 6/13/2012 2:32 PM, Ian Stakenvicius wrote:
> On 13/06/12 02:09 PM, Fabian Groffen wrote:
>> On 13-06-2012 12:00:16 -0400, Ian Stakenvicius wrote:
>>> Hey all - I'd like to propose that enewuser forces updates to a
>>> user's home dir and shell whenever it is called, so that if this
>>> changes with new versions of an ebuild it is dealt with
>>> automatically rather than having to modify them in
>>> pkg_postinst/pkg_setup directly.
> 
>> What if some admin purposely changed home or shell for a system
>> account? Would be quite annoying if every update would reset that,
>> wouldn't it?
> 
> 
> 
> 
> I considered this case, and that it might be more appropriate to
> duplicate 'enewuser' into a new call 'eforceuser' (or similar) which
> could be used instead of 'enewuser' in cases when the currently
> provided user settings should be forced.
> 
> I decided against this as it seems also to make sense that users
> created by portage should be controlled by portage.
> 
> I suppose probably the best means of handling this would be to somehow
> detect whether or not the current user settings are default and only
> apply the updates if they are; however a means of doing that (which
> would be transparent to the ebuild) is somewhat beyond my knowledge
> and abilities.
> 

Just a thought: You could introduce a variable that would disable the
forced updates. This could be set in make.conf by any users who prefer
not to have their passwd database updated automatically.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1879 bytes --]

On Wednesday 13 June 2012 14:32:22 Ian Stakenvicius wrote:
> On 13/06/12 02:09 PM, Fabian Groffen wrote:
> > On 13-06-2012 12:00:16 -0400, Ian Stakenvicius wrote:
> >> Hey all - I'd like to propose that enewuser forces updates to a
> >> user's home dir and shell whenever it is called, so that if this
> >> changes with new versions of an ebuild it is dealt with
> >> automatically rather than having to modify them in
> >> pkg_postinst/pkg_setup directly.
> > 
> > What if some admin purposely changed home or shell for a system
> > account? Would be quite annoying if every update would reset that,
> > wouldn't it?
> 
> I considered this case, and that it might be more appropriate to
> duplicate 'enewuser' into a new call 'eforceuser' (or similar) which
> could be used instead of 'enewuser' in cases when the currently
> provided user settings should be forced.
> 
> I decided against this as it seems also to make sense that users
> created by portage should be controlled by portage.

the users only get created by portage if they don't already exist.  so i 
wouldn't say that the user entries in /etc/passwd "belong" to portage.

> I suppose probably the best means of handling this would be to somehow
> detect whether or not the current user settings are default and only
> apply the updates if they are; however a means of doing that (which
> would be transparent to the ebuild) is somewhat beyond my knowledge
> and abilities.

we have egetshell and egethome already.  thus it's fairly easy to detect the 
transition case.  if they installed the older version which set values that 
you now want to change:
if has_version '<foo/pkg-3' && [[ $(egetshell user) == "/bad/shell" ]] ; then
	esetshell user /good/shell
fi
if has_version '<foo/pkg-3' && [[ $(egethome user) == "/old/home" ]] ; then
	esethome user /new/home
fi
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/06/12 03:04 PM, Mike Frysinger wrote:
> 
> we have egetshell and egethome already.  thus it's fairly easy to
> detect the transition case.  if they installed the older version
> which set values that you now want to change: if has_version
> '<foo/pkg-3' && [[ $(egetshell user) == "/bad/shell" ]] ; then 
> esetshell user /good/shell fi if has_version '<foo/pkg-3' && [[
> $(egethome user) == "/old/home" ]] ; then esethome user /new/home 
> fi -mike



This makes sense to me.  Until I can think of a nice way to detect a
change from the default settings set by a previous enewuser call, it
is probably best to require each ebuild to do the above based on their
specific need.

Patch/RFC rescinded.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/Y5dcACgkQ2ugaI38ACPB9gQD/T3xPVAFfQCPGSuutLx/JwBnk
NCV/v5fn76iAVM2vTNsA/jms8yh7v/n1R5WwcAxmw4Ong+y7ufUMDq4jDNE6jJa5
=+sgH
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 876 bytes --]

On Wednesday 13 June 2012 15:11:19 Ian Stakenvicius wrote:
> On 13/06/12 03:04 PM, Mike Frysinger wrote:
> > we have egetshell and egethome already.  thus it's fairly easy to
> > detect the transition case.  if they installed the older version
> > which set values that you now want to change: if has_version
> > '<foo/pkg-3' && [[ $(egetshell user) == "/bad/shell" ]] ; then
> > esetshell user /good/shell fi if has_version '<foo/pkg-3' && [[
> > $(egethome user) == "/old/home" ]] ; then esethome user /new/home
> > fi
> 
> This makes sense to me.  Until I can think of a nice way to detect a
> change from the default settings set by a previous enewuser call, it
> is probably best to require each ebuild to do the above based on their
> specific need.
> 
> Patch/RFC rescinded.

eset{home,shell} don't exist today, so you should implement them :)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] RFC: esethome

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/06/12 03:14 PM, Mike Frysinger wrote:
> 
> eset{home,shell} don't exist today, so you should implement them
> :) -mike

RFC - heavily based on enewuser.

- --- user.eclass           [some timestamp]
+++ user.eclass.esethome  [some other timestamp]
@@ -388,3 +388,63 @@
 }

 fi
+
+# @FUNCTION: esethome
+# @USAGE: <user> <homedir>
+# @DESCRIPTION:
+# Update the home directory in a platform-agnostic way.
+# Required parameters is the username and the new home directory.
+# Specify -1 if you want to set home to the enewuser default
+# of /dev/null.
+# If the new home directory does not exist, it is created.
+# Any previously existing home directory is NOT moved.
+esethome() {
+       _assert_pkg_ebuild_phase ${FUNCNAME}
+
+       # get the username
+       local euser=$1; shift
+       if [[ -z ${euser} ]] ; then
+               eerror "No username specified !"
+               die "Cannot call esethome without a username"
+       fi
+
+       # lets see if the username already exists
+       if [[ ! -n $(egetent passwd "${euser}") ]] ; then
+               ewarn "User does not exist, cannot set home. skipping."
+               return 1
+       fi
+
+       # handle homedir
+       local ehome=$1; shift
+       if [[ -z ${ehome} ]] ; then
+               eerror "No home directory specified !"
+               die "Cannot call esethome without a home directory"
+       fi
+
+       if [[ ${ehome} == "-1" ]] ; then
+               ehome="/dev/null"
+       fi
+       einfo " - Home: ${ehome}"
+
+       # update the home directory
+       case ${CHOST} in
+       *-darwin*)
+               dscl . change "/users/${euser}" home "${ehome}"
+               ;;
+
+       *-freebsd*|*-dragonfly*)
+               pw usermod "${euser}" -d "${ehome}" || die
+               ;;
+
+       *)
+               usermod -d "${ehome}" "${euser}" || die
+               ;;
+       esac
+
+       if [[ ! -e ${ROOT}/${ehome} ]] ; then
+               einfo " - Creating ${ehome} in ${ROOT}"
+               mkdir -p "${ROOT}/${ehome}"
+               chown "${euser}" "${ROOT}/${ehome}"
+               chmod 755 "${ROOT}/${ehome}"
+       fi
+}

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/Y64wACgkQ2ugaI38ACPBZYQD9EzzmBDUon1YUNxaev5ONluAX
2GA32hOyvwGs2ylZPy8A/3RN8VNsa6XI++eHRdwjpsSZLw4sTVpa+fY2LZHSnWsh
=gLrd
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: esethome

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1136 bytes --]

On Wednesday 13 June 2012 15:35:40 Ian Stakenvicius wrote:
> --- user.eclass           [some timestamp]
> +++ user.eclass.esethome  [some other timestamp]
> @@ -388,3 +388,63 @@
>  }
> 
>  fi
> +
> +# @FUNCTION: esethome

has to be inside the giant if block.  so put this above the "fi".

> +# @USAGE: <user> <homedir>
> +# @DESCRIPTION:
> +# Update the home directory in a platform-agnostic way.
> +# Required parameters is the username and the new home directory.
> +# Specify -1 if you want to set home to the enewuser default
> +# of /dev/null.
> +# If the new home directory does not exist, it is created.
> +# Any previously existing home directory is NOT moved.
> +esethome() {
> +       _assert_pkg_ebuild_phase ${FUNCNAME}
> +
> +       # get the username
> +       local euser=$1; shift
> +       if [[ -z ${euser} ]] ; then
> +               eerror "No username specified !"
> +               die "Cannot call esethome without a username"
> +       fi
> +
> +       # lets see if the username already exists
> +       if [[ ! -n $(egetent passwd "${euser}") ]] ; then

"! -n" -> "-z"
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] RFC: esethome

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/06/12 04:51 PM, Mike Frysinger wrote:
> On Wednesday 13 June 2012 15:35:40 Ian Stakenvicius wrote:
>> --- user.eclass           [some timestamp] +++
>> user.eclass.esethome  [some other timestamp] @@ -388,3 +388,63
>> @@ }
>> 
>> fi + +# @FUNCTION: esethome
> 
> has to be inside the giant if block.  so put this above the "fi".
> 
>> +# @USAGE: <user> <homedir> +# @DESCRIPTION: +# Update the home
>> directory in a platform-agnostic way. +# Required parameters is
>> the username and the new home directory. +# Specify -1 if you
>> want to set home to the enewuser default +# of /dev/null. +# If
>> the new home directory does not exist, it is created. +# Any
>> previously existing home directory is NOT moved. +esethome() { +
>> _assert_pkg_ebuild_phase ${FUNCNAME} + +       # get the
>> username +       local euser=$1; shift +       if [[ -z ${euser}
>> ]] ; then +               eerror "No username specified !" +
>> die "Cannot call esethome without a username" +       fi + +
>> # lets see if the username already exists +       if [[ ! -n
>> $(egetent passwd "${euser}") ]] ; then
> 
> "! -n" -> "-z" -mike


So outside of syntax issues like above, anyone have any issues with my
adding this to user.eclass ?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/bNaoACgkQ2ugaI38ACPAFRgEApwLkrsqSIW0nVK4l/dUTRzV9
ijEnbfa+BLc1skwfW4QA+gKgpmsz/K5VqXnVWyXocGqO98RYJL8lL3qm7k0Hs6uZ
=9i38
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: esethome

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 352 bytes --]

Mike Frysinger wrote:
> > +       # lets see if the username already exists
> > +       if [[ ! -n $(egetent passwd "${euser}") ]] ; then
> 
> "! -n" -> "-z"

Does the $() argument ever need to be double quoted, or do all
versions of bash actually have the string argument optional even
though that's not what the man page reads?


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] RFC: esethome

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/06/12 09:27 AM, Peter Stuge wrote:
> Mike Frysinger wrote:
>>> +       # lets see if the username already exists +       if [[
>>> ! -n $(egetent passwd "${euser}") ]] ; then
>> 
>> "! -n" -> "-z"
> 
> Does the $() argument ever need to be double quoted, or do all 
> versions of bash actually have the string argument optional even 
> though that's not what the man page reads?
> 
> 
> //Peter


Ever?  Yes, but only if what is being returned can contain spaces (and
this matters in the way that it's used).  In the case of 'egetent
passwd', afaict no as it doesn't return anything with whitespace in it.

Examples -- this works:

$ bubba="test thing" ; if [ -n "$(echo $bubba)" ]; then echo OK; fi
OK

Example -- this fails:

$ bubba="test thing" ; if [ -n $(echo $bubba) ]; then echo OK; fi
bash: [: test: binary operator expected

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/bOioACgkQ2ugaI38ACPAUegD+JPzG4oX25QcqXYSfp/c2IE5o
aydKUHZonedILskm5UoA/2bnn2PMFh5lm1rXh7H4/2d9MQaghAUlCmMv0/XORQtW
=7fD+
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: esethome

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

On 15-06-2012 09:35:38 -0400, Ian Stakenvicius wrote:
> On 15/06/12 09:27 AM, Peter Stuge wrote:
> > Mike Frysinger wrote:
> >>> +       # lets see if the username already exists +       if [[
> >>> ! -n $(egetent passwd "${euser}") ]] ; then
> >> 
> >> "! -n" -> "-z"
> > 
> > Does the $() argument ever need to be double quoted, or do all 
> > versions of bash actually have the string argument optional even 
> > though that's not what the man page reads?
> 
> Ever?  Yes, but only if what is being returned can contain spaces (and
> this matters in the way that it's used).  In the case of 'egetent
> passwd', afaict no as it doesn't return anything with whitespace in it.
> 
> Examples -- this works:
> 
> $ bubba="test thing" ; if [ -n "$(echo $bubba)" ]; then echo OK; fi
> OK
> 
> Example -- this fails:
> 
> $ bubba="test thing" ; if [ -n $(echo $bubba) ]; then echo OK; fi
> bash: [: test: binary operator expected

Yes, but this works:

$ bubba="test thing" ; if [[ -n $(echo $bubba) ]]; then echo OK; fi
OK

(and he's using [[, not [)

-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] RFC: esethome

[Peter Stuge]

Ian Stakenvicius wrote:
> > Mike Frysinger wrote:
> >>> +       # lets see if the username already exists +       if [[
> >>> ! -n $(egetent passwd "${euser}") ]] ; then
> >> 
> >> "! -n" -> "-z"
> > 
> > Does the $() argument ever need to be double quoted, or do all 
> > versions of bash actually have the string argument optional even 
> > though that's not what the man page reads?
> 
> Ever?  Yes, but only if what is being returned can contain spaces

Sorry, I should have mentioned that I had the case of the empty
string in mind.


//Peter

Re: [gentoo-dev] RFC: esethome

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

On 15-06-2012 15:41:03 +0200, Peter Stuge wrote:
> Ian Stakenvicius wrote:
> > > Mike Frysinger wrote:
> > >>> +       # lets see if the username already exists +       if [[
> > >>> ! -n $(egetent passwd "${euser}") ]] ; then
> > >> 
> > >> "! -n" -> "-z"
> > > 
> > > Does the $() argument ever need to be double quoted, or do all 
> > > versions of bash actually have the string argument optional even 
> > > though that's not what the man page reads?
> > 
> > Ever?  Yes, but only if what is being returned can contain spaces
> 
> Sorry, I should have mentioned that I had the case of the empty
> string in mind.

Here for the same reason, the difference between [[ and [ is essential.

Fabian

-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] RFC: esethome

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

Fabian Groffen wrote:
> > > >>> +       if [[ ! -n $(egetent passwd "${euser}") ]] ; then
> > > >> 
> > > >> "! -n" -> "-z"
> > > > 
> > > > Does the $() argument ever need to be double quoted, or do all 
> > > > versions of bash actually have the string argument optional even 
> > > > though that's not what the man page reads?
> > > 
> > > Ever?  Yes, but only if what is being returned can contain spaces
> > 
> > Sorry, I should have mentioned that I had the case of the empty
> > string in mind.
> 
> Here for the same reason, the difference between [[ and [ is essential.

It's not clear to me why?

[] is shorthand for test. Both test and [[]] in my man bash read:

--8<--
Expressions are composed of the primaries described .. under
CONDITIONAL EXPRESSIONS.
-->8--

There it says:
--8<--
Conditional expressions are used by the [[ compound command and
the test and [ builtin commands
-->8--

and:
--8<--
       -z string
              True if the length of string is zero.
       string
       -n string
              True if the length of string is non-zero.
-->8--

..which does not at all make it clear that the string is actually
optional?

Under Command Substitution it says:
--8<--
Embedded newlines are not deleted, but they may be removed during
word splitting.
..
If the substitution appears within double quotes, word splitting
and pathname expansion are not performed on the results.
-->8--

..confirming that there is some processing of the substitution.


I also did the tests before asking the question. I'm not trying to
say that the code doesn't work on my system. I'm asking if it will
work the same on every version of bash, in spite of what seems to
be a conflict between real world and documentation.


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] RFC: esethome

[Mike Gilbert]

On Fri, Jun 15, 2012 at 10:05 AM, Peter Stuge <peter@stuge.se> wrote:
> Fabian Groffen wrote:
>> > > >>> +       if [[ ! -n $(egetent passwd "${euser}") ]] ; then
>> > > >>
>> > > >> "! -n" -> "-z"
>> > > >
>> > > > Does the $() argument ever need to be double quoted, or do all
>> > > > versions of bash actually have the string argument optional even
>> > > > though that's not what the man page reads?
>> > >
>> > > Ever?  Yes, but only if what is being returned can contain spaces
>> >
>> > Sorry, I should have mentioned that I had the case of the empty
>> > string in mind.
>>
>> Here for the same reason, the difference between [[ and [ is essential.
>
> It's not clear to me why?
>
> [] is shorthand for test. Both test and [[]] in my man bash read:
>
> --8<--
> Expressions are composed of the primaries described .. under
> CONDITIONAL EXPRESSIONS.
> -->8--
>
> There it says:
> --8<--
> Conditional expressions are used by the [[ compound command and
> the test and [ builtin commands
> -->8--
>
> and:
> --8<--
>       -z string
>              True if the length of string is zero.
>       string
>       -n string
>              True if the length of string is non-zero.
> -->8--
>
> ..which does not at all make it clear that the string is actually
> optional?
>
> Under Command Substitution it says:
> --8<--
> Embedded newlines are not deleted, but they may be removed during
> word splitting.
> ..
> If the substitution appears within double quotes, word splitting
> and pathname expansion are not performed on the results.
> -->8--
>
> ..confirming that there is some processing of the substitution.
>
>
> I also did the tests before asking the question. I'm not trying to
> say that the code doesn't work on my system. I'm asking if it will
> work the same on every version of bash, in spite of what seems to
> be a conflict between real world and documentation.
>
>
> //Peter

Word splitting does not occur within double brackets. This is
documented in the bash manual.

http://www.gnu.org/software/bash/manual/bashref.html#Conditional-Constructs

This causes empty output from a command substitution within double
brackets to be treated as a zero-length string.

Re: [gentoo-dev] RFC: esethome

[Peter Stuge]

Mike Gilbert wrote:
> > [] is shorthand for test. Both test and [[]] in my man bash read:
> >
> > --8<--
> > Expressions are composed of the primaries described .. under
> > CONDITIONAL EXPRESSIONS.
> > -->8--

And the next sentence is exactly what you wrote. :)

"Word splitting and pathname expansion are not performed on the words
between the [[ and ]]"


> Word splitting does not occur within double brackets. This is
> documented in the bash manual.
> 
> http://www.gnu.org/software/bash/manual/bashref.html#Conditional-Constructs
> 
> This causes empty output from a command substitution within double
> brackets to be treated as a zero-length string.

Thanks for pointing me to the right place!


//Peter