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
Hello,
the following script bashtest:
#!bash
set -vx
# /**
# *1. BUILD MKMAC
# ***/
eval msdev=\"`cygpath -a "$MSDEV"`\"
# /**
# *2.
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
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. I'm going crazy not being
able to find out why
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"
> >
in. Unless I can figure out how to get
SYSTEM access to the disk through it. :)
Thanks for your responses.
--
View this message in context:
http://old.nabble.com/Problem-with-bash-script-running-under-NT-AUTHORITY%5CSYSTEM-tp26617039p26628439.html
Sent from the Cygwin list mailing list arch
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,
ything. But it doesn't output to error.log,
and it doesn't get to the next command, either. I've tried removing the
existing .gz files in case it was a permission issue, but it still doesn't
produce a .gz file.
I've tried running the script again logged in as me, and it
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
ows
it should be
Also, if it weren't finding gzip.exe, it would say "command not found"
instead of "no such file or directory".
I really hope this isn't some n00b mistake, but I've been hunting around for
a few hours now with no luck. :(
--
View this message
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
bash prompt, bash itself exists.
>>>This happens when bash is started in a rxvt window or a regular Windows
>>>cmd shell window. I don't have this problem with bash-3.0-8.
>
>
> I noticed that too, and am trying to figure out what is going wrong. I
> also noticed that
regular Windows
cmd shell window. I don't have this problem with bash-3.0-8.
I noticed that too, and am trying to figure out what is going wrong. I
also noticed that the libreadline6 dynamic linking is still breaking
tilde-expansion. I intentionally left bash-3.0-9 as a test version, wi
in a rxvt window or a regular Windows
> cmd shell window. I don't have this problem with bash-3.0-8.
I noticed that too, and am trying to figure out what is going wrong. I
also noticed that the libreadline6 dynamic linking is still breaking
tilde-expansion. I intentionally left bash-3.0-9
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 regular Windows
cmd shell window. I don't have this problem with bash-3.0-8.
David
--
>>> 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
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 for the
prompt to appear in the first one) I get a stack dump in the second window:
Hi
I've just discovered that the command line is not always displayed
correctly. This happens both in the 'normal' window you get when clicking on
the cygwin icon, or in an xterm. I first thought it was related to the
setting of PS1. However, I tried to put PS1 the same on a debian system, and
the
Friday, August 27, 2004 3:48 PM
Subject: Fw: Problem with bash colorin'
> Hello ehhmmm excuse me ... I have a problem concernin' bash
> implementation And the problem is: "My bash gone bloody" ... yes,
> that's right everything that was white became
Hello ehhmmm excuse me ... I have a problem concernin' bash
implementation And the problem is: "My bash gone bloody" ... yes,
that's right everything that was white became red and everything that
was grey became cherry-alike .(I'm talking bout fonts)... That happened
without any
Atukuri, Vasudeva_Kumar wrote:
OS: Windows 2000
Cygwin bash version "2.05b.0(9)"
My application is a combination of Fortran and C.
In Fortran Stdout's number is 6.
When I ran the application from the Cygwin console it is giving the
problem and exited.
where there is a write statement to the stdout.
OS: Windows 2000
Cygwin bash version "2.05b.0(9)"
My application is a combination of Fortran and C.
In Fortran Stdout's number is 6.
When I ran the application from the Cygwin console it is giving the
problem and exited.
where there is a write statement to the stdout.
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
thanks to Randall Shultz , i have used xargs and now i can run my scripts
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
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
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 bug ?
If i try the same commands from a d
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 bug ?
If i try the same commands from a d
55 matches
Mail list logo
