bug#9987: RFE: 'groups' command ADD command switches "-0", and "-1"

[Linda A. Walsh]

Pádraig Brady wrote:

> On 11/07/2011 10:27 PM, Linda Walsh wrote:
>>
>>
>> I'd like to request an RFE for the groups command to add 2 switches:
>>
>> -1 - print groups  in 1 column (cf. ls -1)
>> -0 - print groups followed by null (cf. find et al)
>>
>> reasons: have groups with spaces in them.
>>              provide ultimate safety/futureproof with -0
>>
>> ??
>> reasonable?
>
> Hmm. I suppose by extension that `id -Gn` should accept -1 too.
> But do you really want to support group names with spaces?
> `groupadd` for example won't allow this.
> I suppose integration with LDAP etc. might get arbitrary group names.

----
        I already have groups and usernames with spaces in them.

        Just try merging/supporting a Windows environment via linux.

I EVEN have usernames with "\" in them!...

Was required for 'ssh' to work...since when I'm validated as 'user' via 
samba, when I 'ssh' in from a domain workstation, it comes in as user 
"Domain\user".

I just added an extra PW entry for Domain\me, same as "me", and it works...

Fortunately most core utils are mostly agnostic towards these things... 
it's when you get to talking to people who who tell you that spaces and 
backslashes don't belong there cuz God didn't intend it, that you get into
'religious' discussions'....

Anything other a a null (or colon) should be fair game for user/groupnames 
-- I'd feel uncomfortable about control chars, but hey. no reason 
*technically*, why they should be disallowed (policy is separate from 
technical implementation! ;-)).

NT does Unix 1 better -- they alway use a count for strings.  So even 
'nulls' are ok... though windows, like linux uses null-terminated strings.

This leads to interesting hacks in windows where NT-progs can create 
reg-entries and files that Windows progs can't touch/see due to embedded 
nulls.

Might lead to some interesting file portability probs for NT files created 
with an NT inteface, say on an NTFS file system (dunno about FAT), that 
linux couldn't see -- might even be a way for NT to hide stuff from 
linux...especially since linux supports NTFS and FAT...probably not
an issue in FAT.  I'm unsure about NTFS though as it uses the same
naming rules as the registry, I don't see why it wouldn't have the same
"gotcha's".  I do know it's a prob in the registry...various vendors like 
to hide registration data with embedded nulls in them so they can't be 
touched by normal user processes (ms-sysinternals/regdelnull tool will 
wipe them...but not make them readable...would rather it change the nulls 
to spaces or such...)...


>
> Note POSIX is quite specific about the output format for `id`:
---
        Which posix?  there are about 3-4 different versions.

They are NOT compatible.  I.e. a shell script written against the 1988 
(1990?) spec won't necessarily work against the 2008 spec....etc.


	So you can put alot of stock in POSIX, but you better specify which POSIX 
you are talking about ...  as for me, as soon as POSIX became
incompatible with POSIX, i realized, that they'd "lost the way".... ;-)


>
> "−G Output all different group IDs (effective, real, and supplementary) 
only, using the
> format "%u\n". If there is more than one distinct group affiliation, 
output each
> such affiliation, using the format " %u", before the <newline> is output."

Um...   I don't think the same problem would exist in put out 'uid'/rid' 
which are 32-bit unsigned integers, vs. 'UTF-8 encoded strings' for user 
names......   Two different problem spaces...

I mean you *could* add those options for numeric output, but, personally, 
I don't think that would be a logical step.