Ken Brown writes:
> I do have this, and I have no other version of the header. But this
>
>> #define MPFR_VERSION \
>> MPFR_VERSION_NUM(MPFR_VERSION_MAJOR,MPFR_VERSION_MINOR,MPFR_VERSION_PATCHLEVEL)
>
> yields a value of MPFR_VERSION that doesn't include the "-p11". Maybe
> that's what confused g
What's a reliable and efficient way to determine programmatically if the shell
that's running has elevated privileges?
Or if you prefer, how can I tell if the shell was started with "Run as
administrator"?
I'm looking for a solution that's reliable across installations and OS versions.
I want it
On Feb 5 04:43, Andrew Schulman wrote:
> What's a reliable and efficient way to determine programmatically if the shell
> that's running has elevated privileges?
>
> Or if you prefer, how can I tell if the shell was started with "Run as
> administrator"?
id -G | grep -qE '\<544\>' && echo admin
Andrew Schulman wrote:
> What's a reliable and efficient way to determine programmatically if the
> shell> that's running has elevated privileges?
> Or if you prefer, how can I tell if the shell was started with "Run as
> administrator"?
If you search the mailing list archive for "Change PS1
Corinna Vinschen writes:
>> 2. Parse the output of groups or id -G. I can't find any reliable way to do
>> this. For example on my host, when I start a shell with "Run as
>> administrator",
>> the new group I get isn't 544 (Administrators). It's 114 (Local account and
>> member of Administrator
On Feb 5 12:08, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> 2. Parse the output of groups or id -G. I can't find any reliable way to
> >> do
> >> this. For example on my host, when I start a shell with "Run as
> >> administrator",
> >> the new group I get isn't 544 (Administrators). It
Corinna Vinschen writes:
> On Feb 5 04:43, Andrew Schulman wrote:
>> What's a reliable and efficient way to determine programmatically if the
>> shell
>> that's running has elevated privileges?
>>
>> Or if you prefer, how can I tell if the shell was started with "Run as
>> administrator"?
>
>
J. David Boyd writes:
> This doesn't seem to tell me if my shell has been started with 'Run As
> Administrator', it just tells me if my user is contained in the Administrator
> group.
No, you're not in that group unless you have actual administrator
privileges.
> I can start a cygwin shell, and s
> On Feb 5 12:08, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > >> 2. Parse the output of groups or id -G. I can't find any reliable way
> > >> to do
> > >> this. For example on my host, when I start a shell with "Run as
> > >> administrator",
> > >> the new group I get isn't 544 (Admini
>
>
> Andrew Schulman wrote:
> > What's a reliable and efficient way to determine programmatically if the
> > shell> that's running has elevated privileges?
>
> > Or if you prefer, how can I tell if the shell was started with "Run as
> > administrator"?
>
> If you search the mailing list arch
Achim Gratz writes:
> J. David Boyd writes:
>> This doesn't seem to tell me if my shell has been started with 'Run As
>> Administrator', it just tells me if my user is contained in the Administrator
>> group.
>
> No, you're not in that group unless you have actual administrator
> privileges.
BTW,
Andrew Schulman writes:
> OK, I see. Yes, when I Run as administrator I have
>
> $ id -G
> 513 114 1007 1001 0 545 4 66049 11 15 113 4095 66048 262154 405504
>
> which includes 0.
Remove the /etc/group file or the line for the "root" group (or install
/etc/nsswitch.conf and tell it to ignore thos
On Feb 5 09:39, Andrew Schulman wrote:
> >
> >
> > Andrew Schulman wrote:
> > > What's a reliable and efficient way to determine programmatically if the
> > > shell> that's running has elevated privileges?
> >
> > > Or if you prefer, how can I tell if the shell was started with "Run as
> > > a
On Feb 5 15:28, Achim Gratz wrote:
> J. David Boyd writes:
> > This doesn't seem to tell me if my shell has been started with 'Run As
> > Administrator', it just tells me if my user is contained in the
> > Administrator
> > group.
>
> No, you're not in that group unless you have actual administr
Does anyone have experience with how Cygwin behaves with BitLocker? BitLocker
is being rolled out in my corporate environment for all external media and I am
a little concerned whether Cygwin will be able to read/write to external
drives. I do not have local admin access on my machine.
Thanks, B
On Feb 4 14:46, Corinna Vinschen wrote:
> Hi Cygwin friends and users,
>
>
> At long last, I just released the first non-test version of Cygwin
> 1.7.34.
>
> Note: The version number is 1.7.34-6 to allow automatic updating from
> the last 1.7.34-005 test release with new setup versions.
>
DeTracey, Brendan writes:
> Does anyone have experience with how Cygwin behaves with BitLocker?
> BitLocker is being rolled out in my corporate environment for all
> external media and I am a little concerned whether Cygwin will be able
> to read/write to external drives. I do not have local admin
Hi folks,
A new version of Setup, release 2.867, has been uploaded to
https://cygwin.com/setup-x86.exe (32 bit version)
https://cygwin.com/setup-x86_64.exe (64 bit version)
The changes compared to 2.864 are mostly not visible:
- There's one fix to the output when mistyping a command li
I tried installing from this script...
http://pastebin.com/nZjyYRLa
Unfortunately, as you can see, there seems to be a problem with
forwardslashes/backslashes after "C:\cygstore\". I'll try again tomorrow...
Starting cygwin install, version 2.864
User has backup/restore rights
io_stream_cygfile:
J2897 writes:
> Unfortunately, as you can see, there seems to be a problem with
> forwardslashes/backslashes after "C:\cygstore\". I'll try again tomorrow...
That's normal and nothing to worry about.
> package _autorebase comparing versions 000335-1 and 000335-1, result was 0
> package _update-in
Greetings, Andrew Schulman!
>> However, the user token of such a user still contains the Administrators
>> group (I just tested it) and thus the `id -G' test for 544 (or 0 with
>> the old "root" entry in /etc/group) is still valid.
> OK, I see. Yes, when I Run as administrator I have
> $ id -G
This update appears to break the no-X emacs daemon. Specifically, the
process seems to hang, gettingas far as displaying
"Starting Emacs daemon." but not (visibly) further. If you start an
emacsclient from a different window, it is unable to find/connect to
the server. If you are trying to star
Greetings, All!
If I understand correctly, mintty is based on PuTTY code.
However, the PuTTY terminal capabilities are slightly different than of xterm,
and terminfo database have separate profiles for putty/-vt100/-256color.
My question is, what TERM should I use when advertising my caps to a rem
Re: Updated: setup.exe (Release 2.867)
Re: Updated: gcc-4.9.2-2 (x86/x86_64)
Dear Cygwin Team,
i) I refer to [1], more recently to [2]:
"The most visible effect is that Setup will now never downgrade a package."
It downgrades the "gcc" package from 4.9.2-2 to 4.9.2-1 right now [3].
ii) Would
_autorebase
===
This package provides scripts to keep the Cygwin system properly
rebased. By default this happens incrementally, which means after
each run of setup.exe it is determined which packages have been newly
installed and only the dynamic objects provided by those packages are
r
Version 9.4.1-1 of packages
libecpg-compat3
libecpg-devel
libecpg6
libpgtypes3
libpq-devel
libpq5
postgresql
postgresql-client
postgresql-contrib
postgresql-devel
postgresql-doc
postgresql-plperl
postgresql-plpython
are available in the Cygwin distribution:
CYGWIN CHA
Hello,
I just ran setup-x86_64.exe, marked some packages for update, and then
it asked me "Download incomplete. Try again?" while it tried to
download one of the packages. I clicked "No" and setup went ahead and
tried to install them anyway, telling me some kind of "null" error
when it tried to un
On 06/02/15 05:07, Corinna Vinschen wrote:
Hi folks,
A new version of Setup, release 2.867, has been uploaded to
https://cygwin.com/setup-x86.exe (32 bit version)
https://cygwin.com/setup-x86_64.exe (64 bit version)
The changes compared to 2.864 are mostly not visible:
- There's on
On 2/6/2015 2:59 AM, Kal Sze wrote:
Hello,
I just ran setup-x86_64.exe, marked some packages for update, and then
it asked me "Download incomplete. Try again?" while it tried to
download one of the packages. I clicked "No" and setup went ahead and
tried to install them anyway, telling me some ki
On Fri, 2015-02-06 at 07:43 +0100, Marco Atzeri wrote:
> On 2/6/2015 2:59 AM, Kal Sze wrote:
> > Hello,
> >
> > I just ran setup-x86_64.exe, marked some packages for update, and then
> > it asked me "Download incomplete. Try again?" while it tried to
> > download one of the packages. I clicked "No"
On 2/6/2015 12:17 AM, Vasiliy wrote:
Re: Updated: setup.exe (Release 2.867)
Re: Updated: gcc-4.9.2-2 (x86/x86_64)
Dear Cygwin Team,
i) I refer to [1], more recently to [2]:
"The most visible effect is that Setup will now never downgrade a package."
It downgrades the "gcc" package from 4.9.2-
Greetings, Luke Kendall!
>> A new version of Setup, release 2.867, has been uploaded to
>>
>>https://cygwin.com/setup-x86.exe (32 bit version)
>>https://cygwin.com/setup-x86_64.exe (64 bit version)
>>
>> The changes compared to 2.864 are mostly not visible:
>>
>> - There's one fix to
Kal Sze writes:
> 1. I think if the user answers "No", setup should abort the whole
> process;
The question from setup was if you wanted to retry the download, not if
you wanted to abort. You seem to want it to ask another question.
> 2. Alternatively, setup should not try to install the package
Marco Atzeri writes:
> strange as 4.9.2-2 is current for both architecture
>
> $ cygcheck -cd|grep gcc
> gcc-core4.9.2-2
> gcc-fortran 4.9.2-2
> gcc-g++ 4.9.2-2
>
> It could be a side effect of a messy setup
34 matches
Mail list logo
