Volker Hohmann (priv.) writes:
> ++ cygpath -a 'c:\Program Files (x86)\Microsoft Visual Studio 12.0\VC'
> + eval 'msdev="/cygdrive/c/Program' Files '(x86)/Microsoft' Visual Studio
> '12.0/VC"'
> msdev="/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 12.0/VC"
> ++ msdev='/cygdrive/c/Program
On 8/20/2011 11:12 AM, Bram Kouwenberg wrote:
Hello,
I am using Cygwin under Eclipse C/C++. I am trying to compile/run a
simple c program with gcc, but the file is not found by the bash
shell. Neither gcc or ls -la can find the .c file but ls does show the
other contents of the project directory
On 12/4/2010 5:34 PM, Lee wrote:
On 12/4/10, Lee Rothstein wrote:
On 12/4/2010 10:06 AM, Corinna Vinschen wrote:
> On Dec 4 10:05, Lee wrote:
>> On 12/3/10, Eric Blake wrote:
Here's my takeaway, given Corinna's interesting and complete
context, and my intents. (My intentions, BTW, are f
On 12/04/2010 02:49 PM, Lee Rothstein wrote:
> Therefore, instead of using '[A-Z]' to represent caps, I should
> have used (?) the Posixly Correct, '[:upper:]'.
POSIX 2001 and 2008 says that [A-Z] when used as a glob or as a regex is
defined _only_ in the C locale; in all other locales, it's behav
On 12/4/10, Lee Rothstein wrote:
> On 12/4/2010 10:06 AM, Corinna Vinschen wrote:
>
> > On Dec 4 10:05, Lee wrote:
>
> >> On 12/3/10, Eric Blake wrote:
> >>> Read the FAQ. http://www.faqs.org/faqs/unix-faq/shell/bash/, E9.
>
> >> Which says the en_US locale collates the upper and lower case
On 4 December 2010 21:08, Lee wrote:
> So... the reason for setting LANG is a shorthand method of setting
> all the LC_xxx environment variables?
Yes. Setting LC_ALL does that too, but the difference between LC_ALL
and LANG is that LC_ALL takes precedence over the specific LC_xxx
variables, where
On 12/4/2010 10:06 AM, Corinna Vinschen wrote:
> On Dec 4 10:05, Lee wrote:
>> On 12/3/10, Eric Blake wrote:
>>> Read the FAQ. http://www.faqs.org/faqs/unix-faq/shell/bash/, E9.
>> Which says the en_US locale collates the upper and lower case
>> letters like this:
>> AaBb...Zz
>> I got
On 12/4/10, Corinna Vinschen wrote:
> On Dec 4 10:05, Lee wrote:
>> On 12/3/10, Eric Blake wrote:
>> > Read the FAQ. http://www.faqs.org/faqs/unix-faq/shell/bash/, E9.
>>
>> Which says the en_US locale collates the upper and lower case letters like
>> this:
>> AaBb...Zz
>>
>> I got that mu
On Sat, Dec 04, 2010 at 10:05:42AM -0400, Lee wrote:
> > On 12/03/2010 07:11 PM, Lee wrote:
>
> why put the local
> defaults in ~/.bashrc? My understanding is that ~/.bashrc is called
> at every shell startup. Seems like that's one of those things that
> just needs to be set in the login shell,
On Dec 4 10:05, Lee wrote:
> On 12/3/10, Eric Blake wrote:
> > Read the FAQ. http://www.faqs.org/faqs/unix-faq/shell/bash/, E9.
>
> Which says the en_US locale collates the upper and lower case letters like
> this:
> AaBb...Zz
>
> I got that much :) What I don't get is why someone woul
On 12/3/10, Eric Blake wrote:
> On 12/03/2010 07:11 PM, Lee wrote:
>>> Or, is this a bug?
>
> No, but a "feature" of your locale. Set 'export LC_COLLATE=C', and use
> LANG rather than LC_ALL for all your other locale defaults, in your
> ~/.bashrc if you don't like it.
Nice tip - thank you. But
On 12/03/2010 07:11 PM, Lee wrote:
>> Or, is this a bug?
No, but a "feature" of your locale. Set 'export LC_COLLATE=C', and use
LANG rather than LC_ALL for all your other locale defaults, in your
~/.bashrc if you don't like it.
>
> Welcome to the new world order :-0 I tried to figure out why
On 12/3/10, Lee Rothstein wrote:
> Having some problems with bash case-sensitive regexes, so I wrote
> this little test.
... snip ...
> Do I have some Bash or Cygwin parameter set that engenders case
> insensitivity?
Probably the same thing I ran into with LANG != C
try this little test:
$ c
On 2010-12-03 22:30Z, Lee Rothstein wrote:
[script:]
> if [[ "$1" =~ [A-Z] ]] ; then
> echo Contains Capital Letters: $1
> else
> echo Doesn\'t Contain Capital Letters: $1
> fi
[...]
> # WTF, O
> $ t_regex dfgh
> Contains Capital Letters: dfgh
Inspect this option:
shopt -p | grep nocas
On 12/04/2009 03:46 AM, Csaba Raduly wrote:
On Wed, Dec 2, 2009 at 11:50 PM, Larry Hall (Cygwin) wrote:
Remember, SYSTEM is not you.
Unless Louis XIV was a Cygwin user, in which case he might have said
Le systéme, c'est moi!
:-)
On Thu, Dec 3, 2009 at 5:02 PM, Almo<> wrote:
Ok, it's t
On Wed, Dec 2, 2009 at 11:50 PM, Larry Hall (Cygwin) wrote:
> Remember, SYSTEM is not you.
Unless Louis XIV was a Cygwin user, in which case he might have said
Le systéme, c'est moi!
On Thu, Dec 3, 2009 at 5:02 PM, Almo <> wrote:
>
> Ok, it's that SYSTEM running through cygwin has no access to
--- On Wed, 12/2/09, Almo wrote:
> From: Almo
> Subject: Problem with bash script running under NT AUTHORITY\SYSTEM
> To: cygwin@cygwin.com
> Date: Wednesday, December 2, 2009, 4:47 PM
>
> echo "/usr/bin/gzip -f ./$1.sql 2>> error.log"
> >> error.log
> usr/bin/gzip -f ./$1.sql 2>> error.lo
Larry Hall (Cygwin) wrote:
>
> Remember, SYSTEM is not you. It doesn't have your environment or your
> access
> rights. You need to be very careful and explicit with paths, files, and
> their
> permissions. Whatever permissions and paths you have in your environment
> has
> to be replicated
On 12/02/2009 05:39 PM, Almo wrote:
Regarding Moss's suggestion, I did an echo `pwd` in there, and it IS in the
directory I think it is. I do an explicit cd command to make sure of that.
The missing slash is a typo in the message, sorry about that. I've copied
gzip.exe into my working directory,
Dave Korn-6 wrote:
>
> Almo wrote:
>
>> echo "/usr/bin/gzip -f ./$1.sql 2>> error.log" >> error.log
>> usr/bin/gzip -f ./$1.sql 2>> error.log
>>
>> The output I get is:
>>
>> hyperquest_v2.sql
>> /usr/bin/gzip -f ./hyperquest_v2.sql 2>> error.log
>> usr/bin/gzip: No such file or directory
>
Almo wrote:
> echo "/usr/bin/gzip -f ./$1.sql 2>> error.log" >> error.log
> usr/bin/gzip -f ./$1.sql 2>> error.log
>
> The output I get is:
>
> hyperquest_v2.sql
> /usr/bin/gzip -f ./hyperquest_v2.sql 2>> error.log
> usr/bin/gzip: No such file or directory
It's not really as simple as the mis
On 12/02/2009 04:47 PM, Almo wrote:
When this is run from NT AUTHORITY\SYSTEM as a scheduled task, I get an
error. So I put in some debug output: (I also have to specify where gzip.exe
is so that account can find it, hence the "/usr/bin/" part)
echo "/usr/bin/gzip -f ./$1.sql 2>> error.log">>
Almo wrote:
Hi!
I'm using cygwin and this command in a function works when I'm logged in as
me:
gzip -f ./$1.sql 2>> error.log
so it zips hyperquest_v2.sql as the argument I send it is "hyperquest_v2".
When this is run from NT AUTHORITY\SYSTEM as a scheduled task, I get an
error. So I put in
On 3/12/2008 7:21 PM, Eric Blake wrote:
According to David Rothenberger on 3/12/2008 7:04 PM:
| Once the shell starts doing this, it keeps doing it. Restarting bash
| solves the problem.
|
| I first noticed this with cygwin-1.5.25-11, but it happens with -7, too.
Those are old. But it still hap
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to David Rothenberger on 3/12/2008 7:04 PM:
| Once the shell starts doing this, it keeps doing it. Restarting bash
| solves the problem.
|
| I first noticed this with cygwin-1.5.25-11, but it happens with -7, too.
Those are old. But it sti
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Krzysztof Duleba on 7/26/2005 9:12 AM:
> Isn't this caused by the fact that bash returns $? when exits and Ctrl-C
> sets $? to 1? ksh, on the other hand, sets $? to 130 after Ctrl-C.
This is a bug in bash and ksh; POSIX requires $? to ref
Eric Blake wrote:
Something weird is going on. Once I have a shell open, and fire up a
second level bash (non-login), Ctrl-C behaves correctly and cancels the
current line input with exiting the shell. But then when I type exit,
bash returns with exit status 1, even though it did absolutely no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 7/25/2005 12:53 PM:
> According to David Rothenberger on 7/25/2005 12:32 PM:
>
>>>I tried out the new test version of bash-3.0 (bash-3.0-9) and noticed a
>>>problem. When I press Ctrl-C at the bash prompt, bash itself exists
On 7/25/2005 11:53 AM, Eric Blake wrote:
According to David Rothenberger on 7/25/2005 12:32 PM:
I tried out the new test version of bash-3.0 (bash-3.0-9) and noticed a
problem. When I press Ctrl-C at the bash prompt, bash itself exists.
This happens when bash is started in a rxvt window or a re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to David Rothenberger on 7/25/2005 12:32 PM:
> I tried out the new test version of bash-3.0 (bash-3.0-9) and noticed a
> problem. When I press Ctrl-C at the bash prompt, bash itself exists.
> This happens when bash is started in a rxvt window
>>> However, if I wait for eash instance of bash to come to a command prompt
>>> I can start the 2nd, 3rd, etc. bash window. This behavior started after
>>> updating the cygwin library to the latest revision (1.5.13).
>>
>> I'm running with current code (built from CVS earlier today) and I can't
>
Original Message
>From: Dave Korn
>Sent: 03 March 2005 17:48
> Original Message
>> From: Andrew Waltman
>> Sent: 03 March 2005 15:12
>> However, if I wait for eash instance of bash to come to a command prompt
>> I can start the 2nd, 3rd, etc. bash window. This behavior started af
Original Message
>From: Andrew Waltman
>Sent: 03 March 2005 15:12
> Hi,
>
> I frequently start multiple copies of bash at the same time when first
> logging in to my computer. As of the latest update of the cygwin package
> when I start more than one bash at the same time (without waiting
OK OKI'm lamer sorry gotta change standard win term settings
. BUT HOW DID IT GONE RED? I don't remember that I changed defaults
strange ...
- Original Message -
From: "boxforsr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 27, 2004 3:48 PM
Subje
At 10:58 2002-11-14, you wrote:
Igor Pechtchanski wrote:
Well, if you really want something equivalent to 'ls *', you'd need to do
something like
...
Huh?!? Just type ls! You don't need anything else and certainly not
something as complicated as what you propose.
Andrew,
You're not paying
You do if you an argument list that is to large. try using just
ls with 7000 files and see what happens. :-)
On Thu, Nov 14, 2002 at 10:58:53AM -0800, Andrew DeFaria wrote:
> Igor Pechtchanski wrote:
>
> > Well, if you really want something equivalent to 'ls *', you'd need to
> > do something l
Igor Pechtchanski wrote:
Well, if you really want something equivalent to 'ls *', you'd need to
do something like
find . -maxdepth 1 \( -name .\* -o -print \) | xargs ls
The "-maxdepth 1" is to not descend recursively into directories, and
the "-name .\*" is to avoid listing hidden files/dire
Hi, Randy,
Umm, no, we're not going for convolutedness here, we're trying to figure
out how to do an equivalent of globbing without actually expanding the
whole thing on the command line...
You're right about the "./" being prepended to the output of find, and so
I agree with the "sed" suggestion
Hi, Igor,
Well, if we're going to play "what's the most convoluted way you can think
of to do something with a much simpler equivalent," then I should point out
that you need to modify your suggestion thusly:
find . -maxdepth 1 \( -name .\* -o -print \) |sed -e 's/^\.\///' |xargs
ls -d
Firs
Well, if you really want something equivalent to 'ls *', you'd need to do
something like
find . -maxdepth 1 \( -name .\* -o -print \) | xargs ls
The "-maxdepth 1" is to not descend recursively into directories, and the
"-name .\*" is to avoid listing hidden files/directories (which would not
be m
Here is an example..
find . -type f |xargs ls
I came in late and this might not be a solution to your exact
problem but it might at least help get you on the right path.
On Thu, Nov 14, 2002 at 08:29:27AM -0800, Randall R Schulz wrote:
> Claudio,
>
> No, that's not a bug. It's just a (system-
Claudio,
No, that's not a bug. It's just a (system-dependent) limit shared by all
POSIX-compliant systems. The actual limit happens to be on the low side
under Cygwin.
Familiarize yourself with the "xargs" command. It's there just to handle
these cases.
Also, in many cases the programs themse
Claudio Tamietto wrote:
>
> I have installed cigwin on my W2K PC and all is very well
> functioning. However if i try some commands like ls * or
> grep -i -l some_text * from a directory whit a lot of files
> (7-8 thousand) i obtain this error
>
> bash: /usr/bin/ls: Invalid argument
>
> Is it a
43 matches
Mail list logo
