On Mar 23 18:01, Brian Inglis wrote:
> Corinna Vinschen cygwin.com> writes:
> > On Mar 23 12:35, Brian Inglis wrote:
> >> Warren Young etr-usa.com> writes:
> >>> Confirmed, at least on Win10 64-bit without any AD mucking things up.
> >>> That is, I get both 114 and 544 here, so I don’t need the 1
Corinna Vinschen cygwin.com> writes:
> On Mar 23 12:35, Brian Inglis wrote:
>> Warren Young etr-usa.com> writes:
>>> Confirmed, at least on Win10 64-bit without any AD mucking things up.
>>> That is, I get both 114 and 544 here, so I don’t need the 114 rule at all.
>> Opposite for me on Win7 x64
On Mar 23 12:35, Brian Inglis wrote:
> Warren Young etr-usa.com> writes:
> > On Mar 15, 2016, at 2:17 PM, Achim Gratz nexgo.de> wrote:
> >> Andrey Repin writes:
> >>>test $group -eq 114 && { x="#"; break; }
> >> Nope, that group membership isn't associated with real administrative
> >> powers
Warren Young etr-usa.com> writes:
> On Mar 15, 2016, at 2:17 PM, Achim Gratz nexgo.de> wrote:
>> Andrey Repin writes:
>>>test $group -eq 114 && { x="#"; break; }
>> Nope, that group membership isn't associated with real administrative
>> powers.
> Confirmed, at least on Win10 64-bit without a
On Tue, Mar 15, 2016 at 7:19 PM, Warren Young wrote:
>> I'm fairly certain that I have not had this machine that long
>
> The mtimes on those files is as reliable as your system clock, because
> they’re generated during first install.
Turns out I was wrong, I've had the machine since 2014-12-04 a
On Mar 15, 2016, at 5:13 PM, Andrey Repin wrote:
>
> I'll grab it, if you don't mind.
That was the idea. It’s a patch I don’t have to maintain now. :)
Thank you!
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http
On Mar 15, 2016, at 5:19 PM, Warren Young wrote:
>
> On Mar 15, 2016, at 5:14 PM, Erik Soderquist wrote:
>>
>> I'm fairly certain
>> that I have not had this machine that long
>
> The mtimes on those files is as reliable as your system clock, because
> they’re generated during first install.
Greetings, Warren Young!
> On Mar 15, 2016, at 2:17 PM, Achim Gratz wrote:
>>
>> Andrey Repin writes:
>>>test $group -eq 114 && { x="#"; break; }
>>
>> Nope, that group membership isn't associated with real administrative
>> powers.
> Confirmed, at least on Win10 64-bit without any AD muck
On Mar 15, 2016, at 5:14 PM, Erik Soderquist wrote:
>
> I'm fairly certain
> that I have not had this machine that long
The mtimes on those files is as reliable as your system clock, because they’re
generated during first install.
Contrast that with files unpacked from tarballs which can be ba
On Tue, Mar 15, 2016 at 7:03 PM, Warren Young wrote:
> You can still re-generate them with the mkpasswd/mkgroup commands, but that’s
> strongly discouraged.
>
> These files are not removed if present, even when upgrading pre-1.7.34 to
> 2.0+, so if you copied over a prior install’s /etc contents
On Mar 15, 2016, at 5:00 PM, Erik Soderquist wrote:
>
> On Tue, Mar 15, 2016 at 6:53 PM, Warren Young wrote:
>>> I do not know where /etc/passwd and /etc/group came from on
>>> this system, unless pre-1.7.34 is still less than a year ago
>>
>> Google sez: https://cygwin.com/ml/cygwin-announce/2
On Tue, Mar 15, 2016 at 6:53 PM, Warren Young wrote:
>> I do not know where /etc/passwd and /etc/group came from on
>> this system, unless pre-1.7.34 is still less than a year ago
>
> Google sez: https://cygwin.com/ml/cygwin-announce/2014-11/msg00019.html
>
> Relevant: https://cygwin.com/ml/cygw
On Mar 15, 2016, at 4:48 PM, Erik Soderquist wrote:
>
> I do not know where /etc/passwd and /etc/group came from on
> this system, unless pre-1.7.34 is still less than a year ago
Google sez: https://cygwin.com/ml/cygwin-announce/2014-11/msg00019.html
Relevant: https://cygwin.com/ml/cygwin-ann
On Tue, Mar 15, 2016 at 6:43 PM, Warren Young wrote:
>> Also, I have 0... how long ago was 0 and/or /etc/group removed?
>
> 1.7.34, with adjustments in .35 and 2.0.0.
>
> You *really* should consider moving /etc/passwd and /etc/group out of the way
> under 2.0+.
>
> Having done that, does the out
On Mar 15, 2016, at 4:40 PM, Erik Soderquist wrote:
>
> On Tue, Mar 15, 2016 at 6:19 PM, Warren Young wrote:
>> Confirmed, at least on Win10 64-bit without any AD mucking things up. That
>> is, I get both 114 and 544 here, so I don’t need the 114 rule at all.
>
> Looks like AD may muck things
On Tue, Mar 15, 2016 at 6:19 PM, Warren Young wrote:
> Confirmed, at least on Win10 64-bit without any AD mucking things up. That
> is, I get both 114 and 544 here, so I don’t need the 114 rule at all.
Looks like AD may muck things up for those of us stuck with it. I
have neither 114 nor 544, b
On Mar 15, 2016, at 3:34 PM, Thomas Wolff wrote:
>
> Is there also a universal replacement for
>elif id | grep -e "gid=.*(Power Users)" > /dev/null
> ?
Give this a try:
PS1_COLOR=32
PS1_PCHAR='$'
for group in $(id -G); do
test $group -eq 544 && { PS1_PCHAR='#'; PS1_COLOR=31; break; }
On Mar 15, 2016, at 2:17 PM, Achim Gratz wrote:
>
> Andrey Repin writes:
>>test $group -eq 114 && { x="#"; break; }
>
> Nope, that group membership isn't associated with real administrative
> powers.
Confirmed, at least on Win10 64-bit without any AD mucking things up. That is,
I get both
Am 15.03.2016 um 18:08 schrieb Corinna Vinschen:
On Mar 15 12:33, Andrew Schulman wrote:
I just came up with this recipe to change the default PS1 value to use red for
the user@host part of the prompt and to change the $ character to a #:
if id | grep -qi 'member of administrators group'
Andrey Repin writes:
> test $group -eq 114 && { x="#"; break; }
Nope, that group membership isn't associated with real administrative
powers. It just tells you that this is a local account that is normally
in the Administrators group, but you are still in that group when you
drop those privil
On Mar 15, 2016, at 11:23 AM, Andrey Repin wrote:
>
> PS1_TAIL="$(
> x="$"
> for group in $(id -G); do
> {
>test $group -eq 114 && { x="#"; break; }
>test $group -eq 544 && { x="#"; break; }
>test $group -eq 0 && { x="Please remove well-known SID overrides from your
> /etc/group
On Mar 15, 2016, at 12:37 PM, Achim Gratz wrote:
>
> Warren Young writes:
>
>> Perhaps something like this should go into the default /etc/profile?
>
> No, since it gets read for all shells, not just interactive ones.
Not according to the INVOCATION section of bash.1. It only talks about
/et
Warren Young writes:
> I’m not certain the string match on the output of id(1) works
> everywhere. Is there a better way to check for admin privileges under
> Cygwin? You can’t check for UID or EUID == 0, for example, as you’d
> do on a true POSIX system.
{ id -G | grep -Eq '^544$'; } && echo ad
Greetings, Warren Young!
> I just came up with this recipe to change the default PS1 value to use red
> for the user@host part of the prompt and to change the $ character to a #:
> if id | grep -qi 'member of administrators group'
> then
> export PS1=$(echo "$PS1" | sed -e 's_32_3
On Mar 15 12:33, Andrew Schulman wrote:
> > I just came up with this recipe to change the default PS1 value to use red
> > for the user@host part of the prompt and to change the $ character to a #:
> >
> > if id | grep -qi 'member of administrators group'
> > then
> > export PS1=$
> I just came up with this recipe to change the default PS1 value to use red
> for the user@host part of the prompt and to change the $ character to a #:
>
> if id | grep -qi 'member of administrators group'
> then
> export PS1=$(echo "$PS1" | sed -e 's_32_31_' -e 's_\\\$_#_')
>
I just came up with this recipe to change the default PS1 value to use red for
the user@host part of the prompt and to change the $ character to a #:
if id | grep -qi 'member of administrators group'
then
export PS1=$(echo "$PS1" | sed -e 's_32_31_' -e 's_\\\$_#_')
fi
I’m not
27 matches
Mail list logo
