[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Linda A. Walsh
Subject: bug#9987: RFE: 'groups' command ADD command switches "-0", and "-1"
Date: Mon, 07 Nov 2011 17:38:38 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100228 Lightning/0.9 Thunderbird/ Mnenhy/

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]