TL;DR: Weird permissions behavior in a Cygwin installation where
permissions have been changed over time. I can't reproduce it on a
clean install so that's how I'm working around it, but I thought it
might be worth capturing what details I have in case it helps others
or helps identify a bug.
Afte
On 27.07.2020 07:47, Fergus Daly via Cygwin wrote:
Of more than 640 *.c files incorporated into a locally-built executable,
exactly one contains many references
to readline, such as "#include ". The 32-bit build
proceeds impeccably to completion:
there is a subdirectory x86/release/readline in
Of more than 640 *.c files incorporated into a locally-built executable,
exactly one contains many references
to readline, such as "#include ". The 32-bit build
proceeds impeccably to completion:
there is a subdirectory x86/release/readline in the Cygwin resource and a
paragraph for @ readline i
25 AM Marco Atzeri wrote:
> >>>>>>>> On 14.06.2020 08:12, David Karr wrote:
> >>>>>>>>> On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
> >>>>>>>>>> On 13.06.2020 20:53, David Karr via Cygwin w
te:
>>>>>>>>> On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
>>>>>>>>>> On 13.06.2020 20:53, David Karr via Cygwin wrote:
>>>>>>>>>>> I've been using kubectl in Cygwin on Window
o Atzeri wrote:
>>> >>>> On 14.06.2020 08:12, David Karr wrote:
>>> >>>>> On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
>>> >>>>>> On 13.06.2020 20:53, David Karr via Cygwin wrote:
>>> >>>&
t; On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
>> >>>>>> On 13.06.2020 20:53, David Karr via Cygwin wrote:
>> >>>>>>> I've been using kubectl in Cygwin on Windows 10 for quite a while,
>> >>>>>>&g
13.06.2020 20:53, David Karr via Cygwin wrote:
> >>>>>>> I've been using kubectl in Cygwin on Windows 10 for quite a while,
> >>>>>>> to communicate to our in-house k8s clusters. I often use "kubectl
> >>>>>>> exec&quo
> On 14.06.2020 08:12, David Karr wrote:
>>>>> On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
>>>>>> On 13.06.2020 20:53, David Karr via Cygwin wrote:
>>>>>>> I've been using kubectl in Cygwin on Windows 10 for quit
3, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
> >>>> On 13.06.2020 20:53, David Karr via Cygwin wrote:
> >>>>> I've been using kubectl in Cygwin on Windows 10 for quite a while,
> >>>>> to communicate to our in-house k8s clusters. I
n wrote:
>>>>> I've been using kubectl in Cygwin on Windows 10 for quite a while,
>>>>> to communicate to our in-house k8s clusters. I often use "kubectl
>>>>> exec" to open a shell in a container or directly execute a shell
>>
ia Cygwin wrote:
> > I've been using kubectl in Cygwin on Windows 10 for quite
a while, to
> > communicate to our in-house k8s clusters. I often use "kubectl
> exec" to
> > open a shell in a container or direct
been using kubectl in Cygwin on Windows 10 for quite a
> while, to
> > > communicate to our in-house k8s clusters. I often use "kubectl
> > exec" to
> > > open a shell in a container or directly execute a shell command.
> > This has
>
rs. I often use "kubectl
exec" to
> open a shell in a container or directly execute a shell command.
This has
> worked perfectly fine for a long time.
>
> A couple of days ago, I discovered that all of these attempts
were failing
> with &
On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
> On 13.06.2020 20:53, David Karr via Cygwin wrote:
> > I've been using kubectl in Cygwin on Windows 10 for quite a while, to
> > communicate to our in-house k8s clusters. I often use "kubectl exec" to
&
On 13.06.2020 20:53, David Karr via Cygwin wrote:
I've been using kubectl in Cygwin on Windows 10 for quite a while, to
communicate to our in-house k8s clusters. I often use "kubectl exec" to
open a shell in a container or directly execute a shell command. This has
worked perfe
I've been using kubectl in Cygwin on Windows 10 for quite a while, to
communicate to our in-house k8s clusters. I often use "kubectl exec" to
open a shell in a container or directly execute a shell command. This has
worked perfectly fine for a long time.
A couple of days ago, I
On Wed, 4 Mar 2020, Andrey Repin wrote:
> Greetings, Satish Balay!
>
> > I'm seeing the following error from cygwin:
>
> > "environment is too large for exec"
>
> > I can try reducing the env - however - is there an option in cygwin to
> &g
Greetings, Satish Balay!
> I'm seeing the following error from cygwin:
> "environment is too large for exec"
> I can try reducing the env - however - is there an option in cygwin to
> increase the current 'max env'?
As far as I recall, this is an OS l
Hi,
I'm seeing the following error from cygwin:
"environment is too large for exec"
I can try reducing the env - however - is there an option in cygwin to increase
the current 'max env'?
Please include me in cc: in replies.
Thanks,
Satish
--
Note: In a prior
MONETARY=ja_JP.UTF-8; mintty --version
> $ for a in {0..99}; do date; done | uniq -c
>
> Other interesting observations are
>
> 1. To reproduce the problem, LANG needs not be set to
> ja_JP.UTF-8 when "mintty --version" runs, i.e., it can be
> reproduced with:
>
esting observations are
1. To reproduce the problem, LANG needs not be set to
ja_JP.UTF-8 when "mintty --version" runs, i.e., it can be
reproduced with:
$ mintty --version
$ LANG=ja_JP.UTF-8
$ for a in {0..99}; do date; done | uniq -c
2. Once the exec starts
trying to run `emacs`, I get
> >
> > (on zsh) : zsh: exec format error: emacs
> > (on bash): bash: /usr/bin/emacs: cannot execute binary file: Exec format
> > error
>
> Are you sure Cygwin's emacs is the first one in your path? Cygwin's
> /usr/
On Fri, Jan 17, 2020, at 17:16, Ken Brown wrote:
> On 1/17/2020 10:33 AM, Ronald Fischer wrote:
> > When trying to run `emacs`, I get
> >
> > (on zsh) : zsh: exec format error: emacs
> > (on bash): bash: /usr/bin/emacs: cannot execute binary file: Exec format
tputs from
programs compiled with "-mwindows". For example, after running the
command "mintty.exe --version" in a terminal, every "exec" called in
the processes in the same session starts to create a console window
which will be closed instantaneously. As re
". For example, after running the
command "mintty.exe --version" in a terminal, every "exec" called in
the processes in the same session starts to create a console window
which will be closed instantaneously. As results, the display is
always flashing when some scripts
On 1/17/2020 10:33 AM, Ronald Fischer wrote:
> When trying to run `emacs`, I get
>
> (on zsh) : zsh: exec format error: emacs
> (on bash): bash: /usr/bin/emacs: cannot execute binary file: Exec format
> error
Are you sure Cygwin's emacs is the first one in your path?
If I am using the Cygwin package "python", for the purpose of demonstrating
the problem I can write a script like this:
#!/bin/sh
exec python
If I run this it will spawn an extra "sh.exe", but the extra shell will exit
once Python has loaded. However if I use a n
;>>
>>>> I believe my Cygwin version is "2.9.0(0.318/5/3)" (from the uname
>>>> string).
>>>>
>>>> From a mintty window, I use a variation of "kubectl exec" in a script
>>>> to
>>>> run a shell in a containe
>
>> Am 31.07.2018 um 18:15 schrieb David Karr:
>>
>>> I really have no idea if this is a Cygwin problem, just trying to
>>> eliminate variables.
>>>
>>> I believe my Cygwin version is "2.9.0(0.318/5/3)" (from the uname
>>> string).
the uname string).
>>
>> From a mintty window, I use a variation of "kubectl exec" in a script to
>> run a shell in a container in a pod. It appears to run, and I can run
>> processes from that shell in the container, but the curious thing is that
>> I
&g
Am 31.07.2018 um 18:15 schrieb David Karr:
I really have no idea if this is a Cygwin problem, just trying to eliminate
variables.
I believe my Cygwin version is "2.9.0(0.318/5/3)" (from the uname string).
From a mintty window, I use a variation of "kubectl exec" in a scri
I really have no idea if this is a Cygwin problem, just trying to eliminate
variables.
I believe my Cygwin version is "2.9.0(0.318/5/3)" (from the uname string).
>From a mintty window, I use a variation of "kubectl exec" in a script to
run a shell in a container in a pod.
Am 2017-05-18 14:30, schrieb Andrey Repin:
I encountered a rather strange PHP bug I could only reproduce in
cygwin
(32 Bit and 64 Bit).
If you have a working MySQL-Connection and then run exec('rsync')
exec()'ing anything from PHP, especially from PHP running on a
webserver i
(32 Bit and 64 Bit).
> If you have a working MySQL-Connection and then run exec('rsync')
exec()'ing anything from PHP, especially from PHP running on a webserver is a
very, very, very bad idea.
> the next Query produces the Warning:
> PHP Warning: Error while sending QUERY
On 2017-05-17 07:39, Björn Tantau wrote:
> I encountered a rather strange PHP bug I could only reproduce in
> cygwin (32 Bit and 64 Bit).
> If you have a working MySQL-Connection and then run exec('rsync') the
> next Query produces the Warning:
> PHP Warning: Error w
then run exec('rsync') the
next Query produces the Warning:
PHP Warning: Error while sending QUERY packet. PID=15036 in
/home/limora/test.php on line 5
See the attached test.php. It should output:
object(PDOStatement)#2 (1) {
["queryString"]=>
string(16) "SELECT
On 4/12/2017 12:41 PM, Christian Franke wrote:
> cyg Simple wrote:
>> ...
>> But I don't believe that env --ignore-environment should be using execvp
>> and should be using execv instead. That is for the upstream coreutils
>> team to decide though.
>
> Possibly not, as it would also require to ch
cyg Simple wrote:
...
But I don't believe that env --ignore-environment should be using execvp
and should be using execv instead. That is for the upstream coreutils
team to decide though.
Possibly not, as it would also require to check whether PATH is set
later in the command line.
Always u
On 4/11/2017 3:02 PM, Christian Franke wrote:
> cyg Simple wrote:
>>
>>-i, --ignore-environment start with an empty environment
>>
>> A relative use of the executable will not be found if the environment is
>> empty.
>
> Not necessarily (see Linux, *BSD, ...). POSIX says this is
> "implementa
cyg Simple wrote:
-i, --ignore-environment start with an empty environment
A relative use of the executable will not be found if the environment is
empty.
Not necessarily (see Linux, *BSD, ...). POSIX says this is
"implementation-defined" - under the assumption that 'env' uses execvp()
On 4/11/2017 7:10 AM, Christian Franke wrote:
> Thomas Wolff wrote:
>> Am 10.04.2017 um 22:29 schrieb Christian Franke:
>>> A few years after https://cygwin.com/ml/cygwin/2014-09/msg00204.html
>>> I found another use case of an unset PATH variable:
>>>
>>> The configure script from mandoc (http://m
Thomas Wolff wrote:
Am 10.04.2017 um 22:29 schrieb Christian Franke:
A few years after https://cygwin.com/ml/cygwin/2014-09/msg00204.html
I found another use case of an unset PATH variable:
The configure script from mandoc (http://mdocml.bsd.lv/) uses this
interesting approach to query default
Am 10.04.2017 um 22:29 schrieb Christian Franke:
A few years after https://cygwin.com/ml/cygwin/2014-09/msg00204.html
I found another use case of an unset PATH variable:
The configure script from mandoc (http://mdocml.bsd.lv/) uses this
interesting approach to query default CC command from make
s from existing practice.
At least some Linux distros use ".:/bin:/usr/bin" as default path
(https://linux.die.net/man/3/exec). Including the current directory is
IMO a bad idea.
This is apparently inherited from the early days:
The current directory is included on current Debian stable,
On 12/01/2015 01:43 PM, Duncan Roe wrote:
>> Why not just:
>>
>> find . -exec cygpath -wa {} +
>>
>> since cygpath handles more than one file in an invocation (that is,
>> using '-exec {} +' rather than '-exec {} \;' is generally faster).
On Mon, Nov 23, 2015 at 02:23:33PM -0700, Eric Blake wrote:
> On 11/23/2015 01:45 PM, Matt D. wrote:
> > Is there a reason why these produce different results?
> >
> > find . -exec cygpath -wa {} \;
> > find . -exec echo $(cygpath -wa {}) \;
>
> Incorrect quo
On 11/23/2015 01:45 PM, Matt D. wrote:
> Is there a reason why these produce different results?
>
> find . -exec cygpath -wa {} \;
> find . -exec echo $(cygpath -wa {}) \;
Incorrect quoting. You are invoking:
find . -exec echo c:\cygwin\home\you\{} \;
(or whatever ./{} resolves
From: Matt D.
>
> Is there a reason why these produce different results?
>
> find . -exec cygpath -wa {} \;
> find . -exec echo $(cygpath -wa {}) \;
>
> I have to do this which is much slower:
> find . -exec bash -c 'echo $(cygpath -wa {})' \;
>
> O
Is there a reason why these produce different results?
find . -exec cygpath -wa {} \;
find . -exec echo $(cygpath -wa {}) \;
I have to do this which is much slower:
find . -exec bash -c 'echo $(cygpath -wa {})' \;
Or this:
find . | while read a; do echo $(cygpath -wa $a); don
Hello,
I've been using a minimal PHP CLI (command-line interface) compiled
with cygwin as a script interpreter. It works fine for most
applications.
Recently I work on a PHP script involving execution of external
programs. Naturally I code with the functions "exec()" or "syst
On Apr 14 14:54, Pavel Fedin wrote:
> Hello!
>
> I decided to try to return to my GNU make patch making use of spawn() on
> Cygwin. Since upstream project refused to cooperate, i use my own patched
> version of Make. And i came across a problem. When spawn() is used,
> sub-process fails to proce
Hello!
I decided to try to return to my GNU make patch making use of spawn() on
Cygwin. Since upstream project refused to cooperate, i use my own patched
version of Make. And i came across a problem. When spawn() is used,
sub-process fails to process Ctrl-C. Ctrl-C is simply ignored. If i want t
On 3/17/2015 10:02 PM, Achim Gratz wrote:
I've revoked the maxima-exec-clisp sub-package since at the moment it
doesn't survive a rebase of the clisp runtime libraries(*). If you have
that package already installed please uninstall it manually (this should
keep the package maxima
I've revoked the maxima-exec-clisp sub-package since at the moment it
doesn't survive a rebase of the clisp runtime libraries(*). If you have
that package already installed please uninstall it manually (this should
keep the package maxima installed). For new installations just use
max
On Fri, Oct 17, 2014 at 8:20 PM, Corinna Vinschen wrote:
> On Oct 17 19:56, Christian Franke wrote:
>> Now works.
>>
>> cygwin_patches_for_postfix_count++; postfix_patches_for_cygwin_count--; :-)
>
> You seem to like the idea... ;)
Of course. He has to deal with postfix, _you_ have to deal with C
pshot. It calls SetDllDirectory
> >>>>on Cygwin's /bin, and dlopen addiotnally tries to load the DLL with
> >>>>LoadLibraryEx(LOAD_WITH_ALTERED_SEARCH_PATH) if all else failed.
> >>>For some reason, the SetDllDirectory() call has no effect for exec(
aryEx(LOAD_WITH_ALTERED_SEARCH_PATH) if all else failed.
For some reason, the SetDllDirectory() call has no effect for exec():
Testcase:
$ unset PATH
$ uname -srvm
-bash: uname: No such file or directory
$ /bin/uname -srvm
CYGWIN_NT-6.1-WOW64 1.7.33s(0.277/5/3) 20141014 19:44:03 i686
$ /usr
s to load the DLL with
> > >LoadLibraryEx(LOAD_WITH_ALTERED_SEARCH_PATH) if all else failed.
> >
> > For some reason, the SetDllDirectory() call has no effect for exec():
> >
> > Testcase:
> >
> > $ unset PATH
> >
> > $ uname -srvm
> > -bash
f all else failed.
>
> For some reason, the SetDllDirectory() call has no effect for exec():
>
> Testcase:
>
> $ unset PATH
>
> $ uname -srvm
> -bash: uname: No such file or directory
>
> $ /bin/uname -srvm
> CYGWIN_NT-6.1-WOW64 1.7.33s(0.277/5/3) 20141014
t for exec():
Testcase:
$ unset PATH
$ uname -srvm
-bash: uname: No such file or directory
$ /bin/uname -srvm
CYGWIN_NT-6.1-WOW64 1.7.33s(0.277/5/3) 20141014 19:44:03 i686
$ /usr/sbin/alternatives
/usr/sbin/alternatives: error while loading shared libraries: ?: cannot
open shared object file: No
On Oct 10 17:39, Corinna Vinschen wrote:
> On Oct 10 14:13, Arjen Markus wrote:
> > 2014-10-10 13:22 GMT+02:00 :
> > >>2014-10-10 13:24 GMT+02:00 Jan Nijtmans <...>:
> > >>> 2014-10-10 12:34 GMT+02:00 Corinna Vinschen <...>:
> > On Oct 9 11:46, tednolan.net wrote:
> > > I'm pretty sure I
On Oct 10 14:13, Arjen Markus wrote:
> 2014-10-10 13:22 GMT+02:00 :
> >>2014-10-10 13:24 GMT+02:00 Jan Nijtmans <...>:
> >>> 2014-10-10 12:34 GMT+02:00 Corinna Vinschen <...>:
> On Oct 9 11:46, tednolan.net wrote:
> > I'm pretty sure I've got some programs loading Tcl extensions that
> >
Right, that makes sense. There is indeed no way for the package
manager to handle that scenario without external help, such as a PATH
variable that includes the various directories these extra DLLs reside
in.
Regards,
Arjen
2014-10-10 13:22 GMT+02:00 :
> In message
>
> you write:
>>This mig
In message
you write:
>This might the way the pkgIndex.tcl file for this particular extension
>has been implemented, but like Jan says, that is not the Tcl way.
>
>Here is a sample that illustrates the more acceptable procedure:
>
># Tcl package index file, version 1.0
>
>if {![package vsatisfies
This might the way the pkgIndex.tcl file for this particular extension
has been implemented, but like Jan says, that is not the Tcl way.
Here is a sample that illustrates the more acceptable procedure:
# Tcl package index file, version 1.0
if {![package vsatisfies [package provide Tcl] 8.6]} {re
2014-10-10 12:34 GMT+02:00 Corinna Vinschen :
> On Oct 9 11:46, tedno...@bellsouth.net wrote:
>> I'm pretty sure I've got some programs loading Tcl extensions that
>> cd into the directory with the extension dlls, load the extension and then
>> change back to where ever they were.
>
> Hmm. If so,
On Oct 9 11:46, tedno...@bellsouth.net wrote:
> In message <20141009162906.ga25...@calimero.vinschen.de>you write:
> >
> >Any other idea what *might* be broken if we remove CWD from the
> >DLL search path?
> >
> >
> >Corinna
> >
>
> I'm pretty sure I've got some programs loading Tcl extensions th
In message <20141009162906.ga25...@calimero.vinschen.de>you write:
>
>Any other idea what *might* be broken if we remove CWD from the
>DLL search path?
>
>
>Corinna
>
I'm pretty sure I've got some programs loading Tcl extensions that
cd into the directory with the extension dlls, load the extensio
On Oct 9 08:25, Eric Blake wrote:
> On 10/09/2014 04:03 AM, Corinna Vinschen wrote:
>
> > Ok. Or... hmm. The fact that using SetDllDirectory disallows searching
> > the CWD got me thinking twice. Security-wise it would really be the
> > right thing to do. Usually DLLs are in defined search pa
On 10/09/2014 04:03 AM, Corinna Vinschen wrote:
> Ok. Or... hmm. The fact that using SetDllDirectory disallows searching
> the CWD got me thinking twice. Security-wise it would really be the
> right thing to do. Usually DLLs are in defined search paths:
>
> - Application dir
> - Application d
On Oct 8 19:15, Christian Franke wrote:
> Corinna Vinschen wrote:
> >On Sep 15 16:35, Christian Franke wrote:
> >>...
> >I'm somewhat reluctant to add a call to SetDllDirectory to the Cygwin
> >DLL for two reasons.
> >
> >- Calling SetDllDirectory with an explicit dir doesn't just add this dir
> >
Corinna Vinschen wrote:
On Sep 15 16:35, Christian Franke wrote:
...
I'm somewhat reluctant to add a call to SetDllDirectory to the Cygwin
DLL for two reasons.
- Calling SetDllDirectory with an explicit dir doesn't just add this dir
to the search path, it also removes the CWD from the searc
On Sep 15 16:35, Christian Franke wrote:
> Peter Rosin wrote:
> >On 2014-09-13 12:00, Christian Franke wrote:
> >>Note that setting PATH=/bin on Cygwin does not fix the security problem in
> >>the DLL search order. Even with "SafeDllSearchMode" enabled, the current
> >>directory is always checked
Peter Rosin wrote:
On 2014-09-13 12:00, Christian Franke wrote:
Note that setting PATH=/bin on Cygwin does not fix the security problem in the DLL search
order. Even with "SafeDllSearchMode" enabled, the current directory is always
checked before PATH. Running some Cygwin program from /usr/sbi
(sorry for replying to self)
On 2014-09-15 09:44, Peter Rosin wrote:
> Also, SetDllDirectory will kill all attempts to run 32-bit
> Cygwin programs from 64-bit Cygwin (and vice versa).
At least I think so.
Cheers,
Peter
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On 2014-09-13 12:00, Christian Franke wrote:
> Eric Blake wrote:
>> (by passing an actual safe path, and NOT by completely unsetting PATH).
>>
>
> Disagree. The postfix master(8) spawns all of its daemons with PATH unset.
> This IMO does not violate POSIX.
>
> Note that setting PATH=/bin on Cygw
On Fri, Sep 12, 2014 at 9:33 PM, Eric Blake wrote:
> On 09/12/2014 11:02 AM, Christian Franke wrote:
(snip)
>>
>> int main()
>> {
>> unsetenv("PATH");
>
> This is undefined behavior, per POSIX. POSIX recommends that you always
> leave PATH defined to at least a bare minimum of the results of
>
Eric Blake wrote:
On 09/12/2014 05:03 PM, Eric Blake wrote:
On 09/12/2014 04:50 PM, Christian Franke wrote:
Andrey Repin wrote:
Hmm... is postfix actually broken?
Unsetting PATH is IMO sane (from the POSIX POV) if all exec() calls use
absolute path names.
If all exec() calls are made with
On Fri, Sep 12, 2014 at 6:24 PM, Eric Blake wrote:
> On 09/12/2014 02:15 PM, Christian Franke wrote:
unsetenv("PATH");
>>> This is undefined behavior, per POSIX. POSIX recommends that you always
>>> leave PATH defined to at least a bare minimum of the results of
>>> confstr(_CS_PATH, ...)
On 09/12/2014 05:03 PM, Eric Blake wrote:
> On 09/12/2014 04:50 PM, Christian Franke wrote:
>> Andrey Repin wrote:
>>>> Hmm... is postfix actually broken?
>>>> Unsetting PATH is IMO sane (from the POSIX POV) if all exec() calls use
>>>> absolute path
On 09/12/2014 04:50 PM, Christian Franke wrote:
> Andrey Repin wrote:
>>> Hmm... is postfix actually broken?
>>> Unsetting PATH is IMO sane (from the POSIX POV) if all exec() calls use
>>> absolute path names.
>> If all exec() calls are made with full paths,
Andrey Repin wrote:
Hmm... is postfix actually broken?
Unsetting PATH is IMO sane (from the POSIX POV) if all exec() calls use
absolute path names.
If all exec() calls are made with full paths, unsetting $PATH does not improve
security in any way,
Of course. But postfix could be configured to
gt; get-out-of-jail-free card doesn't mean that we can't be nice and improve
>> cygwin1.dll to try and help broken programs that unset PATH.
>
> Hmm... is postfix actually broken?
Yes, from the POSIX point of view. It is doing something that is
documented to have unspecified be
n that we can't be nice and improve
>> cygwin1.dll to try and help broken programs that unset PATH.
> Hmm... is postfix actually broken?
> Unsetting PATH is IMO sane (from the POSIX POV) if all exec() calls use
> absolute path names.
If all exec() calls are made with full paths, un
Eric Blake wrote:
On 09/12/2014 11:02 AM, Christian Franke wrote:
If PATH variable is unset or does not contain /bin or /usr/bin,
exec("/not_bin/program", ...) fails because cygwin DLLs could not be
loaded.
This affects postfix which cleans the environment to the bare minimum
fo
On 09/12/2014 11:02 AM, Christian Franke wrote:
> If PATH variable is unset or does not contain /bin or /usr/bin,
> exec("/not_bin/program", ...) fails because cygwin DLLs could not be
> loaded.
>
> This affects postfix which cleans the environment to the bare minim
If PATH variable is unset or does not contain /bin or /usr/bin,
exec("/not_bin/program", ...) fails because cygwin DLLs could not be loaded.
This affects postfix which cleans the environment to the bare minimum
for security reasons.
(fortunately there is an easy workaround, so thi
On 10/7/2013 4:04 AM, gaillard wrote:
Thanks. Yes there are passwords on shares.
What confuses me is that it works on the first invocation of exec channel.
Is there any reason why it works then ?
There are some corner cases where this might work for an individual user
(i.e. the one that&#
Thanks. Yes there are passwords on shares.
What confuses me is that it works on the first invocation of exec channel.
Is there any reason why it works then ?
On 10/4/2013 7:16 PM, Larry Hall (Cygwin) wrote:
On 10/4/2013 3:26 AM, gaillard wrote:
Hi,
My company uses cygwin to enable client
On 10/4/2013 3:26 AM, gaillard wrote:
Hi,
My company uses cygwin to enable client users to access an application through
open-ssh server via an ssh exec-channel. After the session connects fine, the
firstly created exec channel is able to access the mounted shares installed on
the box (in my
Hi,
My company uses cygwin to enable client users to access an application through
open-ssh server via an ssh exec-channel. After the session connects fine, the
firstly created exec channel is able to access the mounted shares installed on
the box (in my test a Windows Server 2008 R2).
The issue
On Mon, Sep 09, 2013 at 03:23:01AM -, Cron Daemon wrote:
>make: Entering directory `/sourceware1/cygwin-staging/setup'
>gpg: Fatal: can't create directory `/sourceware/cygwin-staging/.gnupg':
>Permission denied
>make: *** [/var/ftp/pub/cygwin/x86/setup.ini] Error 2
>make: Leaving directory `/s
make: Entering directory `/sourceware1/cygwin-staging/setup'
gpg: Fatal: can't create directory `/sourceware/cygwin-staging/.gnupg':
Permission denied
make: *** [/var/ftp/pub/cygwin/x86/setup.ini] Error 2
make: Leaving directory `/sourceware1/cygwin-staging/setup'
--
Problem reports: http:/
make: Entering directory `/sourceware1/cygwin-staging/setup'
gpg: Fatal: can't create directory `/sourceware/cygwin-staging/.gnupg':
Permission denied
make: *** [/var/ftp/pub/cygwin/x86/setup.ini] Error 2
make: Leaving directory `/sourceware1/cygwin-staging/setup'
--
Problem reports: http:/
make: Entering directory `/sourceware1/cygwin-staging/setup'
gpg: Fatal: can't create directory `/sourceware/cygwin-staging/.gnupg':
Permission denied
make: *** [/var/ftp/pub/cygwin/x86/setup.ini] Error 2
make: Leaving directory `/sourceware1/cygwin-staging/setup'
--
Problem reports: http:/
make: Entering directory `/sourceware1/cygwin-staging/setup'
/bin/rm: cannot remove `/var/ftp/pub/cygwin/x86/setup.ini.sig': Permission
denied
/bin/rm: cannot remove `/var/ftp/pub/cygwin/x86/setup.bz2.sig': Permission
denied
make: *** [/var/ftp/pub/cygwin/x86/setup.ini] Error 1
make: Leaving dire
make: Entering directory `/sourceware1/cygwin-staging/setup'
/bin/rm: cannot remove `/var/ftp/pub/cygwin/x86/setup.ini.sig': Permission
denied
/bin/rm: cannot remove `/var/ftp/pub/cygwin/x86/setup.bz2.sig': Permission
denied
make: *** [/var/ftp/pub/cygwin/x86/setup.ini] Error 1
make: Leaving dire
make: Entering directory `/sourceware1/cygwin-staging/setup'
/bin/rm: cannot remove `/var/ftp/pub/cygwin/x86/setup.ini.sig': Permission
denied
/bin/rm: cannot remove `/var/ftp/pub/cygwin/x86/setup.bz2.sig': Permission
denied
make: *** [/var/ftp/pub/cygwin/x86/setup.ini] Error 1
make: Leaving dire
make: Entering directory `/sourceware1/cygwin-staging/setup'
/bin/rm: cannot remove `/var/ftp/pub/cygwin/x86/setup.ini.sig': Permission
denied
/bin/rm: cannot remove `/var/ftp/pub/cygwin/x86/setup.bz2.sig': Permission
denied
make: *** [/var/ftp/pub/cygwin/x86/setup.ini] Error 1
make: Leaving dire
1 - 100 of 429 matches
Mail list logo
