On 6/10/2024 8:12 PM, Holger Klene via Cygwin wrote:
This is:
GNU bash, Version 5.2.21(1)-release (x86_64-pc-cygwin)
Was also reproduced in git-bash 5.2.26(1)-release (also cygwin)
but not in WSL-bash 5.1.16 (independent of cygwin)
This regression is introduced in bash-5.1, Introduced changes in
Am 10.06.2024 um 13:12 schrieb Holger Klene via Cygwin:
Hi Cygwin,
On reading a magic value back from a bash variable, the involved command (wc,
grep, cat, ...) hangs indefinitely and has to be stopped by Ctrl+C
Editing it's content by deleting lines, the "magic" goe
Hi Cygwin,
On reading a magic value back from a bash variable, the involved command (wc,
grep, cat, ...) hangs indefinitely and has to be stopped by Ctrl+C
Editing it's content by deleting lines, the "magic" goes away. Also as
demonstrated, other text-files (even twice the
On Sat, 5 Dec 2020 at 15:25, tzccinct wrote:
>
> Hi,
>
> I have found an environment variable that has a strange name `!::'
> (exclamation mark + colon + colon) on my terminal (both mintty and Tera
> Term). The value is also strange, `::\' (colon + colon + backslash).
Hi,
I have found an environment variable that has a strange name `!::'
(exclamation mark + colon + colon) on my terminal (both mintty and Tera
Term). The value is also strange, `::\' (colon + colon + backslash).
$ env | sort | head -n 3
!::=::\
_=/usr/bin/env
ALLUSERSPROFILE=C:\P
Greetings, Jason Vas Dias!
> I am a complete novice Windows user, I have used only BSD / Solaris
> / AIX / HP-UX / MacOSX / z/OS or Linux since 1990, so I am an advanced UNIX
> shell script user & C/C++ + LISP + PERL programmer (I prefer LISP nowadays).
> I have to run a script with an altern
Hi Jason,
On Fri, Nov 20, 2020 at 02:52:09PM +, cygwin wrote:
>
> Good day -
>
> I am using a fairly up-to-date Cygwin:
>release: cygwin
>arch: x86_64
>setup-timestamp: 1603379981
>include-setup: setup <2.878 not supported
>setup-minimum-version: 2.895
>setup-version:
Good day -
I am using a fairly up-to-date Cygwin:
release: cygwin
arch: x86_64
setup-timestamp: 1603379981
include-setup: setup <2.878 not supported
setup-minimum-version: 2.895
setup-version: 2.905
, bash version : 4.4.12(3)-release
on Windows 10 :
Edition Windows 1
On Wed, Oct 28, 2020, at 7:09 PM, Ken Brown wrote:
>
> I won't have time to check this until tomorrow, but I'm guessing that the
> following patch will fix the problem:
>
> --- a/src/emacs.c
> +++ b/src/emacs.c
> @@ -170,7 +170,7 @@ #define MAIN_PROGRAM
> We mark being in the exec'd process
[Please don't top-post on this list.]
On 10/28/2020 9:44 PM, noosph...@mailc.net wrote:
(gdb) bt full
#0 exit (code=1) at /usr/src/debug/cygwin-3.1.7-1/newlib/libc/stdlib/exit.c:54
No locals.
#1 0x0001800496e3 in cygwin_exit (n=1) at
/usr/src/debug/cygwin-3.1.7-1/winsup/cygwin/dcrt0.cc:12
--daemon
Starting program: /usr/local/apps/emacs-27.1/bin/emacs-27.1.exe -Q --daemon
[New Thread 3220.0x16ec]
warning: Application
"\??\C:\cygwin64\usr\local\apps\emacs-27.1\bin\emacs-27.1.exe" found in cache
[New Thread 3220.0x16b0]
emacs: Invalid function: make-local-variable
Error: ser
On 10/28/2020 5:09 PM, noosphere--- via Cygwin wrote:
When trying to start emacs with "emacs --daemon" (with or without the
-Q option, I immediately get an error:
emacs: Invalid function: make-local-variable
Error: server did not start correctly
Thanks for the report. I can
Thanx all who helped out with this
The reason to why we thought it worked in mysterious ways was a coincidence of
how it worked in cygwin shell (due to /etc/profile etc) and that we didn't
realize/investigate that the variable was NULL at this moment and that we fell
back to our own de
Greetings, Kristian Ivarsson via Cygwin!
> If the user sets its TMP-variable to "C:\Jabba Dabba Dooo" or "/jabba dabba
> doo", I expect the value of getenv("TMP") should be just that and regardless
> of OS the value returned is whatever the variable is set t
On 2020-09-17 23:56, Kristian Ivarsson via Cygwin wrote:
>
>>>>>>>>> Does anyone know the rational with this behaviour and what can be
>>>>>>>>> done to get hold of the (real) Windows TMP/TEMP
>>>>>>>>&
>>>>>>>> Does anyone know the rational with this behaviour and what can be
>>>>>>>> done to get hold of the (real) Windows TMP/TEMP
>>>>>>>> environment-variable-values (in a
>>>>>>>> (hopefully)
>> P_tmpdir is '/tmp'
>> tmpnam() is '/tmp/t707.0'
>> tempnam() is '/tmp/d187.2'
>>
>> # start cmd.exe
>> $ /cygdrive/c/windows/system32/cmd.exe
>> Microsoft Windows [Version 10.0.18363.1082]
>> (c) 2019 Microsoft Corpor
)'
$TMPDIR is '(null)'
$TEMP is '(null)'
P_tmpdir is '/tmp'
tmpnam() is '/tmp/t709.0'
tempnam() is '/tmp/d189.2'
P_tmpdir is defined in
Sorry, but I'm missing your point. How is this related to Kristian's claim that
Cyg
On Thu, 17 Sep 2020 at 15:56, Ken Brown via Cygwin <> wrote:
>
#include
#include
int
main ()
{
char *temp_nam;
char *p_tmp_nam;
printf ("$TMP is '%s'\n", getenv ("TMP"));
printf ("$TMPDIR is '%s'\n", getenv ("TMPDIR"));
printf ("$TEMP is '%s'\n", getenv ("TEMP"));
On 9/17/2020 5:07 PM, Kristian Ivarsson via Cygwin wrote:
Does anyone know the rational with this behaviour and what can be
done to get hold of the (real) Windows TMP/TEMP
environment-variable-values (in a
(hopefully) platform independent way) ?
so if you are making your custom tree, try to
>>>>>> Does anyone know the rational with this behaviour and what can be
>>>>>> done to get hold of the (real) Windows TMP/TEMP
>>>>>> environment-variable-values (in a
>>>>>> (hopefully) platform independent
On 9/16/2020 7:12 AM, Thomas Wolff wrote:
Am 16.09.2020 um 13:04 schrieb marco atzeri via Cygwin:
On Wed, Sep 16, 2020 at 10:53 AM Kristian Ivarsson via Cygwin
wrote:
Dear folks
Does anyone know why cygwin annex the TMP (and TEMP) environment variable(s)
and sets them to /tmp for cygwin
Am 17.09.2020 um 14:12 schrieb Kristian Ivarsson via Cygwin:
Does anyone know the rational with this behaviour and what can be
done to get hold of the (real) Windows TMP/TEMP
environment-variable-values (in a
(hopefully) platform independent way) ?
so if you are making your custom tree, try
> >>> Does anyone know the rational with this behaviour and what can be
> >>> done to get hold of the (real) Windows TMP/TEMP
> >>> environment-variable-values (in a
> >>> (hopefully) platform independent way) ?
>
> >> so if you are ma
-variable-values
(in a
(hopefully) platform independent way) ?
so if you are making your custom tree, try to stick on that expectation
and have both directories.
In general, you are free to set TMP to a directory of your choice,
that's the purpose of that variable, no need to sync it with
Am 16.09.2020 um 13:04 schrieb marco atzeri via Cygwin:
On Wed, Sep 16, 2020 at 10:53 AM Kristian Ivarsson via Cygwin
wrote:
Dear folks
Does anyone know why cygwin annex the TMP (and TEMP) environment variable(s)
and sets them to /tmp for cygwin-built-applications (executables) ?
This
On Wed, Sep 16, 2020 at 10:53 AM Kristian Ivarsson via Cygwin
wrote:
>
> Dear folks
>
> Does anyone know why cygwin annex the TMP (and TEMP) environment variable(s)
> and sets them to /tmp for cygwin-built-applications (executables) ?
>
> This results in that when you want
Dear folks
Does anyone know why cygwin annex the TMP (and TEMP) environment variable(s)
and sets them to /tmp for cygwin-built-applications (executables) ?
This results in that when you want the current users TMP-folder you end up
with the /tmp path. As a result,when writing to that, without
l Moore wrote:
>
> I'm not sure if I'm misunderstanding the documentation of the "glob"
> option in the CYGWIN environment variable. I have (this is under
> Powershell Core 7.0.0-rc2):
>
> $env:CYGWIN="glob:ignorecase winsymlinks:native"
>
> if I then t
I'm not sure if I'm misunderstanding the documentation of the "glob"
option in the CYGWIN environment variable. I have (this is under
Powershell Core 7.0.0-rc2):
$env:CYGWIN="glob:ignorecase winsymlinks:native"
if I then try to grep in a file that exists, using
Hi Ken,
> I think you're probably right. The use of FE_NNF in execvp* was
> introduced in
> commit 6d63272b. I suspect it was just an oversight that the spawvp*
> functions
> weren't changed in the same way. I'll send a patch to the cygwin-
> patches list
> to fix this. When Corinna returns
On 10/7/2019 4:51 PM, donpedro.tdcadsl.dk via cygwin wrote:
> Hi all,
>
> While working on something i noticed that execvp* and spawnvp* behave
> differently with regards to $PATH, which i think is not correct.
>
> --
>
> 1) The execvp* functions are
Hi all,
While working on something i noticed that execvp* and spawnvp* behave
differently with regards to $PATH, which i think is not correct.
--
1) The execvp* functions are called like this:
return spawnve ( _P_OVERLAY | _P_PATH_TYPE_EXEC ,
On 2019-08-29 05:05, L A Walsh wrote:
> On 2019/07/20 16:30, Nikos Balkanas wrote:
>>>
>>> Attached is the zipped cygcheck output with user names crossed out
>>>
>
> Worry, but your attachment of the output never came through. Neither
> did mind.
>
> Looks like the mailing list software dis
Seems so.
However, I was lucky enough to fix my problem on my own:)
BR,
Nikos
On Thu, Aug 29, 2019 at 2:05 PM L A Walsh wrote:
>
> On 2019/07/20 16:30, Nikos Balkanas wrote:
> >>
> >> Attached is the zipped cygcheck output with user names crossed out
> >>
>
> Worry, but your attachment of the o
On 2019/07/20 16:30, Nikos Balkanas wrote:
>>
>> Attached is the zipped cygcheck output with user names crossed out
>>
Worry, but your attachment of the output never came through. Neither
did mind.
Looks like the mailing list software discards cygcheck.out output now,
which
seems to make th
Problem was windows line breaks:(
On Sat, Jul 20, 2019 at 9:34 PM Nikos Balkanas wrote:
>
> According to cygwin setup instructions we have to unset certain
> windows environment variables to prevent unpredictable windows
> behavior.
> When I try that in my ~/.bashrc
> [...]
> unset TMPDIR
> unset
On 2018-11-09 03:24, Václav Haisman wrote:
> I have updated Cygwin after a while and now my prompt looks like
> this: \ufeffUSER@MACHINE. There appears to be some sort of UNICODE
> character at position 0 in $USER environment variable. Running `echo -n
> $USER | od -t x1` prints `
Hi.
I have updated Cygwin after a while and now my prompt looks like
this: \ufeffUSER@MACHINE. There appears to be some sort of UNICODE
character at position 0 in $USER environment variable. Running `echo -n
$USER | od -t x1` prints `000 ef bb bf 68 61 69 76 61 30 31`. Does
anyone else
login shell is a POSIX shell and you don't
use Windows applications if you have set a system or user variable
CYGWIN_NOWINPATH to a non-empty value. For tcsh I have patched
/etc/csh.login to do the moral equivalent; I guess that should be
packaged with tcsh eventually.
It's usually way eas
#x27;t need one if your login shell is a POSIX shell and you don't
> use Windows applications if you have set a system or user variable
> CYGWIN_NOWINPATH to a non-empty value.
If-if-if.
What if I explicitly do not want to do that?
It reduces interoperability to miniscule levels.
> It
Am 05.04.2018 um 11:19 schrieb Peter Bauer:
i was bitten by the length limit of the PATH variable of 4095 characters
(see [1]) and could not find a way around it. This means i have a lot of
software packages in different directories and each of them adds itself
to the PATH so one can run the
ell and you don't
use Windows applications if you have set a system or user variable
CYGWIN_NOWINPATH to a non-empty value. For tcsh I have patched
/etc/csh.login to do the moral equivalent; I guess that should be
packaged with tcsh eventually.
It's usually way easier to add to a clean pat
Greetings, Peter Bauer!
> hi,
> i was bitten by the length limit of the PATH variable of 4095 characters
> (see [1]) and could not find a way around it. This means i have a lot of
> software packages in different directories and each of them adds itself
> to the PATH so
On 2018-04-05 04:05, Wolf Geldmacher wrote:
> On 05.04.2018 11:19, Peter Bauer wrote:
>> i was bitten by the length limit of the PATH variable of 4095 characters (see
>> [1]) and could not find a way around it. This means i have a lot of software
>> packages in different di
On Thu, 5 Apr 2018 11:19:01, Peter Bauer wrote:
i was bitten by the length limit of the PATH variable of 4095 characters
(see [1]) and could not find a way around it. This means i have a lot of
software packages in different directories and each of them adds itself
to the PATH so one can run
On 05.04.2018 11:19, Peter Bauer wrote:
hi,
i was bitten by the length limit of the PATH variable of 4095
characters (see [1]) and could not find a way around it. This means i
have a lot of software packages in different directories and each of
them adds itself to the PATH so one can run the
hi,
i was bitten by the length limit of the PATH variable of 4095 characters
(see [1]) and could not find a way around it. This means i have a lot of
software packages in different directories and each of them adds itself
to the PATH so one can run the executables and have the shared libs
Greetings, David Karr!
> I currently do not set the HOME environment variable. I get the
> impression you're not supposed to do that. When I run a mintty shell,
> it correctly puts me in "/home/", which is what I want.
> I'm running into a problem with Eclip
I currently do not set the HOME environment variable. I get the
impression you're not supposed to do that. When I run a mintty shell,
it correctly puts me in "/home/", which is what I want.
I'm running into a problem with Eclipse egit, as I think it's looking
for the &q
On 2018-02-27 03:37 PM, Vince Rice wrote:
>> On Feb 27, 2018, at 2:29 PM, Kaz Kylheku <920-082-4...@kylheku.com> wrote:
>>
>> On 2018-02-27 09:10, Numien wrote:
>>> Jürgen Wagner nailed it; it was my antivirus, and disabling the
>>> shellcode injection check fixed it.
>> However, this time-wasting
> On Feb 27, 2018, at 2:29 PM, Kaz Kylheku <920-082-4...@kylheku.com> wrote:
>
> On 2018-02-27 09:10, Numien wrote:
>> Jürgen Wagner nailed it; it was my antivirus, and disabling the
>> shellcode injection check fixed it.
>
> However, this time-wasting pattern of dealing with the issue by end use
On 2018-02-27 09:10, Numien wrote:
Jürgen Wagner nailed it; it was my antivirus, and disabling the
shellcode injection check fixed it.
However, this time-wasting pattern of dealing with the issue by end
users
is not a good way.
A better approach would be to identify some common paterns of BL
Jürgen Wagner nailed it; it was my antivirus, and disabling the
shellcode injection check fixed it.
Thanks everyone for the help.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe
going back to the mailing list...
On 27/02/2018 16:53, Jürgen Wagner wrote:
Hi,
the expression you posted works on my Cygwin. However, I've had
similar failures in the past.
If you are a user of Comodo CIS/AntiVirus, check out the settings for
shellcode injection.
Enable the checks, allow all
On 2018-02-27 07:12, Numien wrote:
> While working on diagnosing an issue with autotools, I found Cygwin's
> bash seems to not be able to set a variable from backtick substitution,
> at least on my system (Cygwin x86_64, updated today, on Win10)
> On a Linux system it works as e
On 27/02/2018 15:47, Andrey Repin wrote:
Greetings, Numien!
While working on diagnosing an issue with autotools, I found Cygwin's
bash seems to not be able to set a variable from backtick substitution,
at least on my system (Cygwin x86_64, updated today, on Win10)
On a Linux syst
Greetings, Numien!
> While working on diagnosing an issue with autotools, I found Cygwin's
> bash seems to not be able to set a variable from backtick substitution,
> at least on my system (Cygwin x86_64, updated today, on Win10)
> On a Linux system it works as expected:
>
On 2/27/2018 9:12 AM, Numien wrote:
> While working on diagnosing an issue with autotools, I found Cygwin's
> bash seems to not be able to set a variable from backtick substitution,
> at least on my system (Cygwin x86_64, updated today, on Win10)
>
>
> On a Linux syst
Hi,
We use Cygwin build and its command prompt in our use cases.
Currently, We are facing a problem to retrieve environment variable values in
JVM program. Please find details of issue below :
Version details : Currently, cygwin1.7.33 is being used on windows (tried on
server 2008R2, server
On 5/11/2017 9:14 PM, ChampS wrote:
> Hi,
>
> I want to use Cygwin to access all Windows applications installed on my
> Windows 7 system. The Problem is that Windows is using spaces in its
> environment variable 'Path' and Cygwin can not handle the spaces. Is
> th
On Thu, May 11, 2017 at 9:07 PM, Brian Inglis wrote:
> Cygwin has no problem with paths containing spaces.
That may be somewhat of an oversimplification. Due to the way we do
backups at work, my Cygwin "root" is installed in a path that contains
spaces. Most things work OK, but Xwin is unable t
per quoting, even if you 100% know the
> variable content is "safe", unless the results of not using quoting are
> actually desired.
There's lots of contexts where you don't need quoting, as the shell uses the
variable and contents and does the right thing, but there is
Greetings, Brian Inglis!
>> Someone an idea how I could solve this issue?
> If your scripts use environment variables, they should be careful
> to enclose uses of those variables in double quotes "$VAR".
Correction: You should always use proper quoting, even if you
On 05/11/2017 10:44 PM, Eliot Moss wrote:
On 5/11/2017 9:14 PM, ChampS wrote:
Hi,
I want to use Cygwin to access all Windows applications installed on my
Windows 7 system. The
Problem is that Windows is using spaces in its environment variable 'Path'
and Cygwin can not handle
the
On 2017-05-11 19:14, ChampS wrote:
> I want to use Cygwin to access all Windows applications installed on
> my Windows 7 system. The Problem is that Windows is using spaces in
> its environment variable 'Path' and Cygwin can not handle the spaces.
> Is there a way to use t
On 5/11/2017 9:14 PM, ChampS wrote:
Hi,
I want to use Cygwin to access all Windows applications installed on my Windows
7 system. The
Problem is that Windows is using spaces in its environment variable 'Path' and
Cygwin can not handle
the spaces. Is there a way to use the Windows e
Hi,
I want to use Cygwin to access all Windows applications installed on my
Windows 7 system. The Problem is that Windows is using spaces in its
environment variable 'Path' and Cygwin can not handle the spaces. Is
there a way to use the Windows environment variable 'Path'
ygwin and in doing so, I have ran into a
> problem with some application because Cygwin seems to be appended to
> my PATH environment variable. I have tried to remove this by following
> these instructions https://www.java.com/en/download/help/path.xml but
> something strange happens.
On Thu, Mar 23, 2017 at 2:10 PM, Tanya Sandoval
wrote:
> I recently had to reinstall Cygwin and in doing so, I have ran into a
> problem with some application because Cygwin seems to be appended to
> my PATH environment variable. I have tried to remove this by following
> these instru
On 3/23/2017 3:10 PM, Tanya Sandoval wrote:
> I recently had to reinstall Cygwin and in doing so, I have ran into a
> problem with some application because Cygwin seems to be appended to
> my PATH environment variable. I have tried to remove this by following
> these instru
Hi,
I recently had to reinstall Cygwin and in doing so, I have ran into a
problem with some application because Cygwin seems to be appended to
my PATH environment variable. I have tried to remove this by following
these instructions https://www.java.com/en/download/help/path.xml but
something
[Sorry, forgot to reply-all...]
Am 15.03.2017 um 23:48 schrieb Jeffrey Walton:
Since Coverity is
complaining about an implicit conversion, maybe the following will
help to avoid the implicit part (and sidestep the finding):
if (free != NULL)
break;
Or perhaps:
if ((void*)free
Am 26.11.2016 um 04:42 schrieb Brian Inglis:
On Debian both yacc and bison.yacc are alternatives;
Not exactly. bison.yacc is a script; the same one that Cygwin's bison
package installed as /usr/bin/yacc. Debian obviously renamed it. They
have to do that because their yacc is an alternativ
On 2016-11-25 17:08, Hans-Bernhard Bröker wrote:
Am 25.11.2016 um 15:31 schrieb Brian Inglis:
One solution, and the most common in Cygwin, is the package flex should
create a symlink lex if no such symlink or exe exists;
In this case I believe that would be less than fully correct, because
fl
Am 25.11.2016 um 15:31 schrieb Brian Inglis:
One solution, and the most common in Cygwin, is the package flex should
create a symlink lex if no such symlink or exe exists;
In this case I believe that would be less than fully correct, because
flex is not a clean drop-in replacement for generic
U Flex,
the lex command is nonexistent; thus the $(LEX) Make
variable fails.
It's not $(LEX) that's failing here; it's the way you form
expectations about what $(LEX) is supposed to be. The value of $(LEX)
is clearly documented to default to 'lex' (see "info make i
the $(LEX) Make
variable fails.
It's not $(LEX) that's failing here; it's the way you form expectations
about what $(LEX) is supposed to be. The value of $(LEX) is clearly
documented to default to 'lex' (see "info make implicit implicit").
If the insta
ckage maintainers.
Anyway, even though my Cygwin installation has GNU Flex,
the lex command is nonexistent; thus the $(LEX) Make
variable fails.
Either LEX should go to "flex", or there should be a
"lex" alias.
If the installation has some sort of lex, the
predefined $(LEX) vari
ygwin installation has GNU Flex,
the lex command is nonexistent; thus the $(LEX) Make
variable fails.
Either LEX should go to "flex", or there should be a
"lex" alias.
If the installation has some sort of lex, the
predefined $(LEX) variable should resolve to it.
--
Problem reports
On 19/10/2016 16:47, Nellis, Kenneth wrote:
Normally, I open a Cygwin terminal window by clicking on a Windows icon
which is an alias to a .BAT file which prepares environment variables
for my Cygwin session and then invokes mintty thusly:
start /b C:\cygwin64\bin\mintty -i/Cygwin-Terminal.ico
Normally, I open a Cygwin terminal window by clicking on a Windows icon
which is an alias to a .BAT file which prepares environment variables
for my Cygwin session and then invokes mintty thusly:
start /b C:\cygwin64\bin\mintty -i/Cygwin-Terminal.ico -s80,57 -
Nothing unusual there, but I have
On Thu, Sep 4, 2014 at 9:25 PM, Brandon Huber wrote:
>
> are there any instances where using "xterm" would cause incorrect or
> unexpected behavior?
Compatibility commentary is available at:
* http://en.wikipedia.org/wiki/Rxvt
* The top of the /usr/share/doc/rxvt/etc/rxvt.terminfo file.
* The "
Hi,
I know that the proper value for the TERM environment variable for the
non-unicode Cygwin rxvt is "rxvt-cygwin-native", but are there any
instances where using "xterm" would cause incorrect or unexpected
behavior? I have a co-worker who has started a holy war to chang
Greetings, Larry Hall (Cygwin)!
>> It looks like /etc/profile sets LC_ALL=C before running the scripts
>> in /etc/profile.d, then restores it to its original setting. This
>> prevents LANG getting set by lang.sh.
>>
> Good catch. Yes, the latest version of base_files makes this change to
> the p
Larry Hall (Cygwin cygwin.com> writes:
> Good catch. Yes, the latest version of base_files makes this change to
> the profile_d() function. Looks like the easiest interim solution is to
> downgrade to base_files-4.1-2.
The easiest interim solution is probably to unset LC_ALL or revert to
_LC_SA
David Rothenberger wrote:
It looks like /etc/profile sets LC_ALL=C before running the scripts
in /etc/profile.d, then restores it to its original setting. This
prevents LANG getting set by lang.sh.
The statement LC_ALL=C has been introduced in /et/profile with the
recent upgrade of base-file 4
On 04/24/2014 05:56 PM, David Rothenberger wrote:
Angelo Graziosi wrote:
I remember that some time ago I had, in mintty,
$ echo $LANG
it_IT.UTF-8
Now LANG is empty ('echo $LANG' prints nothing).
I notice that /etc/profile.d has lang.sh which should set LANG when I
start mintty. That script co
Angelo Graziosi wrote:
> I remember that some time ago I had, in mintty,
>
> $ echo $LANG
> it_IT.UTF-8
>
> Now LANG is empty ('echo $LANG' prints nothing).
>
> I notice that /etc/profile.d has lang.sh which should set LANG when I
> start mintty. That script contains
>
> test -z "${LC_ALL:-${LC
On 04/24/2014 05:13 PM, Angelo Graziosi wrote:
I remember that some time ago I had, in mintty,
$ echo $LANG
it_IT.UTF-8
Now LANG is empty ('echo $LANG' prints nothing).
I notice that /etc/profile.d has lang.sh which should set LANG when I start
mintty. That script contains
test -z "${LC_ALL:-
I remember that some time ago I had, in mintty,
$ echo $LANG
it_IT.UTF-8
Now LANG is empty ('echo $LANG' prints nothing).
I notice that /etc/profile.d has lang.sh which should set LANG when I
start mintty. That script contains
test -z "${LC_ALL:-${LC_CTYPE:-$LANG}}" && export LANG=$(/usr/bin
> I can't respond to David Stacey's original mail but I think he should
> get a gold star for persevering and figuring this out:
>
> http://cygwin.com/ml/cygwin/2013-11/msg00484.html
Awarded: http://cygwin.com/goldstars/#DSt
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On Dec 3 11:10, Christopher Faylor wrote:
> On Tue, Dec 03, 2013 at 05:05:07PM +0100, Corinna Vinschen wrote:
> >On Dec 3 10:43, Christopher Faylor wrote:
> >> I can't respond to David Stacey's original mail but I think he should
> >> get a gold star for persevering and figuring this out:
> >>
>
On Tue, Dec 03, 2013 at 05:05:07PM +0100, Corinna Vinschen wrote:
>On Dec 3 10:43, Christopher Faylor wrote:
>> I can't respond to David Stacey's original mail but I think he should
>> get a gold star for persevering and figuring this out:
>>
>> http://cygwin.com/ml/cygwin/2013-11/msg00484.html
>
On Dec 3 10:43, Christopher Faylor wrote:
> I can't respond to David Stacey's original mail but I think he should
> get a gold star for persevering and figuring this out:
>
> http://cygwin.com/ml/cygwin/2013-11/msg00484.html
I agree. I should have thought about this myself.
Corinna
--
Corin
I can't respond to David Stacey's original mail but I think he should
get a gold star for persevering and figuring this out:
http://cygwin.com/ml/cygwin/2013-11/msg00484.html
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation
On Dec 2 21:19, Jason Tishler wrote:
> Corinna,
>
> On Sun, Dec 01, 2013 at 01:23:00PM +0100, Corinna Vinschen wrote:
> > On Nov 30 06:32, David Stacey wrote:
> > > Jason Tishler: As rebase maintainer, if you agree with my diagnosis
> > > then please could you make new versions of 'rebase' contai
Corinna,
On Sun, Dec 01, 2013 at 01:23:00PM +0100, Corinna Vinschen wrote:
> On Nov 30 06:32, David Stacey wrote:
> > Jason Tishler: As rebase maintainer, if you agree with my diagnosis
> > then please could you make new versions of 'rebase' containing the
> > fix for both architectures. Thank you
: perl is attempting
> >to load some modules (IO.dll, MD5.dll, Fcnt.dll, Cwd.dll), which
> >fail with rebase errors. The script waits five seconds before
> >trying (and failing) again; this repeats ad infinitum.
>
> I am pleased to report that I have tracked down the cause of
nt.dll, Cwd.dll), which fail with rebase
errors. The script waits five seconds before trying (and failing)
again; this repeats ad infinitum.
I am pleased to report that I have tracked down the cause of my rebase
woes to an uninitialised variable in the 'rebase' package. A simple
patch (at
1 - 100 of 435 matches
Mail list logo