Am 24/10/2022 um 11:36 schrieb marco atzeri:
On Sun, Oct 23, 2022 at 7:27 PM Ferenc Valenta wrote:
Hi,
Just found a possible issue with Cygwin:
If cygwin is not on the default path, and make is started by specyfing
the path to it (e.g., c:\cygwin64\bin\make), $(MAKE) works in the
top
On Sun, Oct 23, 2022 at 7:27 PM Ferenc Valenta wrote:
>
>
> Hi,
>
> Just found a possible issue with Cygwin:
> If cygwin is not on the default path, and make is started by specyfing
> the path to it (e.g., c:\cygwin64\bin\make), $(MAKE) works in the
> top-level makefi
Hi,
Just found a possible issue with Cygwin:
If cygwin is not on the default path, and make is started by specyfing
the path to it (e.g., c:\cygwin64\bin\make), $(MAKE) works in the
top-level makefile, but it does not work in make includes.
To reproduce the issue, use these files:
makefile
On 2020-11-24 00:24, Thomas Wolff wrote:
Am 19.11.2020 um 16:57 schrieb Brian Inglis:
On 2020-11-17 16:41, tealhill via Cygwin wrote:
On 2020-11-17 4:23 PM, Thomas Wolff wrote:
Am 17.11.2020 um 20:54 schrieb tealhill via Cygwin:
>>
Cygwin's /etc/profile sets the PATH.
Could /etc/profile
On 24/11/2020 14:52, Bill Stewart wrote:
> On Tue, Nov 24, 2020 at 12:25 AM Thomas Wolff wrote:
>
>>> and please note that SysNative appears nowhere!
>> That's because Sysnative is not a known folder. It is rather unknown
>> just because it is virtual :)
>> And that is the problem I tried to
On Tue, Nov 24, 2020 at 12:25 AM Thomas Wolff wrote:
> > and please note that SysNative appears nowhere!
>
> That's because Sysnative is not a known folder. It is rather unknown
> just because it is virtual :)
> And that is the problem I tried to address. In cygwin32, you can `cd
>
Am 19.11.2020 um 16:57 schrieb Brian Inglis:
On 2020-11-17 16:41, tealhill via Cygwin wrote:
On 2020-11-17 4:23 PM, Thomas Wolff wrote:
Am 17.11.2020 um 20:54 schrieb tealhill via Cygwin:
>>
Cygwin's /etc/profile sets the PATH.
Could /etc/profile please also add
On 2020/11/17 15:41, tealhill via Cygwin wrote:
### Summary
Why should Cygwin add Sysnative to $PATH? As a workaround for
Microsoft's failure to add Sysnative to %PATH%.
### Full explanation
Cygwin imports the Windows %PATH% variable at startup.
It would be ideal if Microsoft would add
On 2020-11-17 16:41, tealhill via Cygwin wrote:
On 2020-11-17 4:23 PM, Thomas Wolff wrote:
Am 17.11.2020 um 20:54 schrieb tealhill via Cygwin:
>>
Cygwin's /etc/profile sets the PATH.
Could /etc/profile please also add /cygdrive/c/Windows/Sysnative to the end
of the PATH?
>
It doesn't
Greetings, tealhill!
> On 2020-11-17 4:23 PM, Thomas Wolff wrote:
>> Am 17.11.2020 um 20:54 schrieb tealhill via Cygwin:
>>>
>>> Cygwin's /etc/profile sets the PATH.
>>>
>>> Could /etc/profile please also add /cygdrive/c/Windows/Sysnative to
>>> the end of the PATH?
>>
>> It doesn't add any
tealhill via Cygwin writes:
> ### Summary
>
> Why should Cygwin add Sysnative to $PATH? As a workaround for
> Microsoft's failure to add Sysnative to %PATH%.
With my maintainer hat for base-files on, I reject this proposal.
As already noted, there is no precedent for Cygwin doing things like
On Tue, Nov 17, 2020 at 4:42 PM tealhill via Cygwin wrote:
> Therefore, I am suggesting that Cygwin work around Microsoft's omission.
> My suggested workaround is for Cygwin to add Sysnative to its own
> $PATH, automatically.
I don't think that should be a default behavior in cygwin and is
On 2020-11-17 4:23 PM, Thomas Wolff wrote:
Am 17.11.2020 um 20:54 schrieb tealhill via Cygwin:
>>
Cygwin's /etc/profile sets the PATH.
Could /etc/profile please also add /cygdrive/c/Windows/Sysnative to
the end of the PATH?
>
It doesn't add any other Windows folders so why this one.
###
Am 17.11.2020 um 20:54 schrieb tealhill via Cygwin:
Dear all:
### Background information (you can skip this)
...
### The problem
32-bit tools, such as 32-bit Cygwin, don't usually see the real
System32 directory. Instead, when they try to look inside System32,
Windows shows them the
Dear all:
### Background information (you can skip this)
I use Pluckeye 0.99.60 for Windows. This is a self-control tool,
available online. It can help to stop me from visiting certain
time-wasting websites.
I also use Pluckeye's command-line component, pluck.exe. [I invoke the
tool
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
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
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
>
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
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
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
C)\\n" | env -i make -sf -`
This works at least on Linux, (Free|Net|Open)BSD and OpenIndiana. It
fails on Cygwin because 'env -i' unsets everything and execvp() does not
use a default path then. This is OK from the POSIX
("implementation-defined") point of view but differs fr
Cygwin and Cygwin-X terminals always have default $PATH containing all the
Windows paths. This gives many problems both in the terminals running
command line commands and also NetBeans IDE. How to change the default $PATH
so it does not contain any Windows paths? i.e. just
/usr/local/bin:/usr/bin
2010/9/29 cygwindummy liu...@gmail.com:
Cygwin and Cygwin-X terminals always have default $PATH containing all the
Windows paths. This gives many problems both in the terminals running
command line commands and also NetBeans IDE. How to change the default $PATH
so it does not contain any
Here I means when running bash or other shell in non-interactive mode,
how can I set up environment variables, and without touch the Win32
System Environment?
Default PATH, for example. When PATH variable isn't set, there is a
default PATH. But if you set the PATH variable, the default
so that I can run commands in the
/usr/bin directory, with the ./ ?
--
View this message in context:
http://www.nabble.com/How-do-I-set-the-default-path--tp20840873p20840873.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Unsubscribe info: http://cygwin.com/ml
walterbyrd wrote:
I am new to cygwin. I am running cygwin on XP.
When I start cygwin, I am put into the /usr/bin directory. I can not run
anything, even ls, without putting a ./ in front of it.
I am using this XP box at work. I am able to directly change my windows
path.
Is there a way
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Christopher Faylor on 2/12/2006 9:57 AM:
I don't mind protecting people against the evil 3PP which corrupt the
PATH but, as I said, since we don't get that many complaints about the
current behavior (which may actually have been in
On Sun, Feb 12, 2006 at 12:26:22PM -0800, Yitzchak Scott-Thoennes wrote:
On Sun, Feb 12, 2006 at 11:57:00AM -0500, Christopher Faylor wrote:
If we don't get a single person indicating that they rely on the
current behavior then I'm ok with changing it. We have a patch ready
to be checked in, in
On Sat, February 11, 2006 8:41 pm, Christopher Faylor wrote:
We're
just trying go figure out if removing the ;; translation will affect
many people. We're not looking to add things to the PATH.
There is a tradeoff here and I don't believe that we really know what
the implications are. You
On Feb 11 15:24, Stephan Mueller wrote:
cgf wrote:
So, I don't think this really answers Corinna's question. I believe that
she was looking for documentation which stated that ;; was ignored, not
reasoning which implies it.
In the absence of the former, I'd hope the latter would be
On Feb 12 08:44, John Morrison wrote:
On Sat, February 11, 2006 8:41 pm, Christopher Faylor wrote:
We're
just trying go figure out if removing the ;; translation will affect
many people. We're not looking to add things to the PATH.
There is a tradeoff here and I don't believe that we
On Feb 11 20:22, Eric Blake wrote:
I strongly oppose option 3 - cygwin should never add '.' implicitly to the
front of a POSIX path - if you are crazy enough to want dot there, put
it there yourself explicitly. But I like option 2, of squeezing ';;' into a
single ':' (avoiding the implicit
On Sun, February 12, 2006 11:58 am, Corinna Vinschen wrote:
On Feb 12 08:44, John Morrison wrote:
On Sat, February 11, 2006 8:41 pm, Christopher Faylor wrote:
We're
just trying go figure out if removing the ;; translation will affect
many people. We're not looking to add things to the
On Feb 12 13:52, John Morrison wrote:
On Sun, February 12, 2006 11:58 am, Corinna Vinschen wrote:
On Feb 12 08:44, John Morrison wrote:
Would a reasonable solution would be to make the PATH environment
variable
a special case and parse it when set? (Appologies if this isn't a
On Sun, Feb 12, 2006 at 01:03:18PM +0100, Corinna Vinschen wrote:
On Feb 11 20:22, Eric Blake wrote:
I strongly oppose option 3 - cygwin should never add '.' implicitly to
the front of a POSIX path - if you are crazy enough to want dot there,
put it there yourself explicitly. But I like option 2,
On Sun, Feb 12, 2006 at 11:57:00AM -0500, Christopher Faylor wrote:
If we don't get a single person indicating that they rely on the current
behavior then I'm ok with changing it. We have a patch ready to be
checked in, in fact.
I assume that:
$ PATH=/foo::$PATH cmd /c printenv PATH
will
On 10 February 2006 19:01, Corinna Vinschen wrote:
On Feb 8 18:59, Dave Korn wrote:
Since POSIX semantics requires an empty path component to be treated as
$CWD, but Win32 semantics require an empty path component to be ignored,
On Friday, Feb 10, Corinna wrote:
On Feb 8 18:59, Dave Korn wrote:
On 08 February 2006 13:06, Eric Blake wrote:
Yes, this is correct behavior, but it often catches people by surprise.
POSIX requires an empty string in your PATH to be treated as the current
directory, and while people
There are two different points of view possible here:
- Changing an empty Win32 path component to a POSIX . entry is in
Cygwin for a long time. It's possible that people rely on this
behaviour, so changing it would break existing installations.
Removing . from $PATH could
On Sat, Feb 11, 2006 at 12:02:47PM -0800, Stephan Mueller wrote:
On Friday, Feb 10, Corinna wrote:
On Feb 8 18:59, Dave Korn wrote:
On 08 February 2006 13:06, Eric Blake wrote:
Yes, this is correct behavior, but it often catches people by surprise.
POSIX requires an empty string in your
Eric writes:
There are two different points of view possible here:
- Changing an empty Win32 path component to a POSIX . entry is in
Cygwin for a long time. It's possible that people rely on this
behaviour, so changing it would break existing installations.
Removing .
cgf wrote:
On Sat, Feb 11, 2006 at 12:02:47PM -0800, Stephan Mueller wrote:
On Friday, Feb 10, Corinna wrote:
On Feb 8 18:59, Dave Korn wrote:
On 08 February 2006 13:06, Eric Blake wrote:
Yes, this is correct behavior, but it often catches people by surprise.
POSIX requires an
On Feb 8 18:59, Dave Korn wrote:
On 08 February 2006 13:06, Eric Blake wrote:
Yes, this is correct behavior, but it often catches people by surprise.
POSIX requires an empty string in your PATH to be treated as the current
directory, and while people are less likely to start their Windows
Solution is to reinstall 'base-files' (see
http://www.cygwin.com/ml/cygwin/2006-02/msg00222.html).
My PATH was appended with '.' because of a trailing ';' in my Windows PATH.
Thank you.
--
jt
On 2/6/06, Eric Blake [EMAIL PROTECTED] wrote:
I upgrade to 1.5.19-4 and my default PATH has changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ugh - top-posting reformatted. http://cygwin.com/acronyms/#TOFU
On 2/6/06, Eric Blake ericblake AT comcast DOT net wrote:
Ugh - http://cygwin.com/acronyms/#PCYMTNQREAIYR
PATH is inherited from my WinXP
On 08 February 2006 13:06, Eric Blake wrote:
PATH is inherited from my WinXP environment as usual but it is not
prepend with /bin like before the upgrade, and is now appended with
..
According to Julien Thewys on 2/8/2006 2:58 AM:
Solution is to reinstall 'base-files' (see
I upgrade to 1.5.19-4 and my default PATH has changed:
PATH is inherited from my WinXP environment as usual but it is not
prepend with /bin like before the upgrade, and is now appended with
..
I cannot find where this happen (my .bashrc is unchanged).
Also, when I start cygwin (shell in rxvt
I upgrade to 1.5.19-4 and my default PATH has changed:
PATH is inherited from my WinXP environment as usual but it is not
prepend with /bin like before the upgrade, and is now appended with
..
I cannot find where this happen (my .bashrc is unchanged).
Try opening a cmd.com window in c
snip
Try opening a cmd.com window in c:\cygwin\bin (or whatever it is
named), then running 'bash --login -xv' to see every command executed
by bash during startup. Maybe that will help you pinpoint the
culprit.
This really helps understand why it takes so long to open a bash shell,
the login
51 matches
Mail list logo
