X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=TYErQoclkNJ99nRf7JLl4lAi1dDruRukNNnzyJ9QiC4
	8kLXYTqREPDnggkRQZ4AMlmI6QFNYVQCfVrG+ak5W8sMKdayfBPzXV1kSGBS5Myy
	qNmcEC1D+r1WFfgDN6wsp6kbTy8FqlYnIJPsxt/7Bda1H7x0UtqScpmyybUrrlA0
	=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 s=default; bh=6leIitfCij70F5b6cylfWHT++6o=; b=Twr8u7Dn1e7GGAvnP
	p0wBw6EVEIV129HDnQ6DGHIGe212ioAutA7UM0hVV3tPTDWUagHz6T9/Mc4JGHvX
	/pFgxTyBb4BrdSEFYFSp4yVzC9GL4C0qpoeIKTNGbbimvScKDMhcs4HMK9ntsTth
	KmHcGhrLwZlxdTwjOg6iSaLwNE=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO: mailout05.t-online.de
Message-ID: <545C68BA.3050007@t-online.de>
Date: Fri, 07 Nov 2014 07:37:46 +0100
From: Christian Franke <Christian DOT Franke AT t-online DOT de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.6
References: <announce DOT 20141105164319 DOT GA31314 AT calimero DOT vinschen DOT de> <545B17B8 DOT 5010509 AT t-online DOT de> <20141106164915 DOT GG28195 AT calimero DOT vinschen DOT de> <545BBF4B DOT 4020400 AT t-online DOT de> <20141106185019 DOT GK28195 AT calimero DOT vinschen DOT de> <545BD14A DOT 8080803 AT t-online DOT de> <20141106200635 DOT GP28195 AT calimero DOT vinschen DOT de> <20141106204222 DOT GQ28195 AT calimero DOT vinschen DOT de>
In-Reply-To: <20141106204222.GQ28195@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

Corinna Vinschen wrote:
> On Nov  6 21:06, Corinna Vinschen wrote:
>> On Nov  6 20:51, Christian Franke wrote:
>>> Corinna Vinschen wrote:
>>>> On Nov  6 19:34, Christian Franke wrote:
>>>>> But why does
>>>>>    mkpasswd -l (no host) -- adds a prefix
>>>>>    mkpasswd -l THISHOST -- does not add a prefix
>>>>> when the machine is in a domain? Not consistent, IMO.
>>>> That's right.  The reason is that the machine name is treated as a
>>>> foreign machine.  In theory, this should always generate names
>>>> with prefixed machine name, but this is an entirely different
>>>> code path in mkpasswd/mkgroup.  I guess this should be fixed.
>>>>
>>>> I wouldn't be unhappy about help...
>>> I would only fix it back to the old behaviour (mkpasswd -l = no prefix),
>>> sorry :-)
>>>
>>> At my real job we run several build & test machines which are members of a
>>> domain but use various local test user accounts (with no collision with
>>> domain users due to name space rules). Loosing the ability to use
>>> prefix-less local user names would break various existing test scripts
>>> (which are also used on Linux).
>>>
>>> Generated emails would have a from address with HOST+USER name part which
>>> might give interesting results if the mail system somehow interprets the
>>> NAME+EXTENSION address syntax...
>>>
>>> So there are use cases where prefix-less local user names are needed. This
>>> should be still supported, e.g. by mkpasswd -l, IMO.
>> But then... why not keep mkpasswd -L and use that instead?
> On second thought, it's completely wrong to allow printing local
> accounts from another machine without prefix.

I agree.

> In theory there should be only one option -l [machine], which prints the
> local accounts of the current machine unprefixed (standalone machine) or
> prefixed (domain machine), and always prefixed for a foreign machine.
> The -L option can just go away.

I disgree.

Why not keep the old behavior of -l/-L for user names of current machine 
for those uses cases which rely on it? Those users who are happy with 
prefixed local user names and non-prefixed domain user names would 
simply no longer need to use mkpasswd (which is good).

Package search shows 156 usr/bin/*-config scripts. How many of these use 
mkpasswd?

BTW: None of my Linux machines have local user names with own HOSTNAME 
as prefix :-)

Christian


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple