Jason Pyeron via Cygwin writes:
> I have been wondering if an A/B directory approach may help.
> Run from Cygwin.A, update Cygwin.B, stop processes and switch A and B.
>
> Thoughts?
You can have as many Cygwin installations on a single machine as you can
tell apart and they are all
On Sat, Aug 31, 2024 at 4:51 PM Andrey Repin via Cygwin
wrote:
>
> Greetings, Jason Pyeron!
>
> > Sad to admit, but I have not updated Cygwin in a very long time.
>
> > It takes a very long (more than an hour) time to update Cygwin due to the
> > amount of items installed. …
Sorry if I mention s
gt; I have been wondering if an A/B directory approach may help.
> Run from Cygwin.A, update Cygwin.B, stop processes and switch A and B.
> Thoughts?
The best course is to endure and upgrade.
May be review the list of installed packages and remove those unused first.
> I know this does n
time.
I have been wondering if an A/B directory approach may help.
Run from Cygwin.A, update Cygwin.B, stop processes and switch A and B.
Thoughts?
I know this does not address the I have 60+ minty running, but this approach
can be done while rebooting.
There's no fundamental problem
Sad to admit, but I have not updated Cygwin in a very long time.
It takes a very long (more than an hour) time to update Cygwin due to the
amount of items installed. I have not had the luxury of nor running Cygwin
processes in that update time.
I have been wondering if an A/B directory
On 2018-10-16 10:57, Gary Johnson wrote:
> On 2018-10-16, Peder Sverdrup via cygwin wrote:
>> I am making a script and need to know when the computer was last booted.
>> This can be done with who -b command. I have installed the minimum cygwin
>> and this command is not availa
On 10/16/2018 11:36 AM, Peder Sverdrup via cygwin wrote:
> Hi,
>
> I am making a script and need to know when the computer was last booted.
> This can be done with
>
> who -b command. I have installed the minimum cygwin and this command is not
> available.
>
> Which p
On 10/16/18 12:57 PM, Gary Johnson wrote:
> On 2018-10-16, Peder Sverdrup via cygwin wrote:
>> Hi,
>>
>> I am making a script and need to know when the computer was last booted.
>> This can be done with
>>
>> who -b command. I have installed the minimum cygw
On 2018-10-16, Peder Sverdrup via cygwin wrote:
> Hi,
>
> I am making a script and need to know when the computer was last booted.
> This can be done with
>
> who -b command. I have installed the minimum cygwin and this command is not
> available.
>
> Which package do
On 10/16/2018 5:36 PM, Peder Sverdrup via cygwin wrote:
> Hi,
>
> I am making a script and need to know when the computer was last booted.
> This can be done with
>
> who -b command. I have installed the minimum cygwin and this command is not
> available.
>
> Which p
Hi,
I am making a script and need to know when the computer was last booted.
This can be done with
who -b command. I have installed the minimum cygwin and this command is not
available.
Which package do I need to install in order to have this command available
(or any other command
that can
On Sat, 8 Jul 2017 13:45:38 +0100, Jon Turney wrote:
> The i686-pc-mingw32 toolchain was removed from Cygwin a while ago [1].
Many thanks - very enlightening! Obviously I missed this info. So a useless
patch.
> [1] https://cygwin.com/ml/cygwin-announce/2016-03/msg00069.html
--
Problem reports
On 08/07/2017 09:32, Jannick wrote:
On Jul 03, 2017 at 01:12 PM, Jannick wrote:
On Mon, 3 Jul 2017 09:25:51 +0200, Corinna Vinschen wrote:
[...]
I am not sure what the code basis of i686-pc-mingw32 is, so am back here on
this list with the patch.
Maybe there is someone out here who knows how
On Jul 03, 2017 at 01:12 PM, Jannick wrote:
> of function 'glob'
>
> On Mon, 3 Jul 2017 09:25:51 +0200, Corinna Vinschen wrote:
>
> > This is, in fact, the wrong mailing list. The files for the mingw
> > cross build environment are maintained via the mingw-w64-public
> > mailing list on sourcefo
On Mon, 3 Jul 2017 09:25:51 +0200, Corinna Vinschen wrote:
> This is, in fact, the wrong mailing list. The files for the mingw
> cross build environment are maintained via the mingw-w64-public
> mailing list on sourceforge, see
>
> https://sourceforge.net/p/mingw-w64/mailman/
>
> Ideally yo
Hi Jannick,
On Jul 1 15:44, Jannick wrote:
> Attached a tiny patch to i686-pc-mingw32' glob.h which remedies a function
> prototype definition error thrown upon compilation.
>
> I am hoping that this is the correct one of cygwin's mail-lists, please
> advise otherwise.
This is, in fact, the wr
Attached a tiny patch to i686-pc-mingw32' glob.h which remedies a function
prototype definition error thrown upon compilation.
I am hoping that this is the correct one of cygwin's mail-lists, please
advise otherwise.
Thanks,
J.
---
C:/cygwin32/usr/i686-pc-mingw32/sys-root/mingw/include/nppBacku
On Jul 14 18:22, Nellis, Kenneth wrote:
> It seems that the length of the string passed to cygpath -w
> affects whether double quotes are translated or not:
>
> $ cygpath -w '"12345"' | od -cAn
>" 1 2 3 4 5 " \n
> $ cygpath -w '"123456"' | od -cAn
>" 1 2 3 4 5 6 3
It seems that the length of the string passed to cygpath -w
affects whether double quotes are translated or not:
$ cygpath -w '"12345"' | od -cAn
" 1 2 3 4 5 " \n
$ cygpath -w '"123456"' | od -cAn
" 1 2 3 4 5 6 357 200 242 \n
$ cygpath --version
cygpath (cygwin) 2.
On Jul 14 11:12, Warren Young wrote:
> On Jul 14, 2016, at 9:24 AM, Warren Young wrote:
> >
> > If you look at such a file name in Explorer, Cygwin (?) seems to be mapping
> > double-quotes to U+F022, which is currently not defined within Unicode:
> >
> > http://www.fileformat.info/info/unicod
On Jul 14, 2016, at 9:24 AM, Warren Young wrote:
>
> If you look at such a file name in Explorer, Cygwin (?) seems to be mapping
> double-quotes to U+F022, which is currently not defined within Unicode:
>
> http://www.fileformat.info/info/unicode/char/f022/
I think this may be a typo in whate
On Jul 14, 2016, at 8:36 AM, Brien Oberstein wrote:
>
> cygpath -w 'a"b' doesn't seem to translate the double quotes into a windows
> accesible file name.
Double quotes are illegal on NTFS:
https://msdn.microsoft.com/library/windows/desktop/aa365247.aspx
cygpath -w 'a"b' doesn't seem to translate the double quotes into a windows
accesible file name.
should it, and if not, what is the proper way to translate from cygwin
filenames with special mapped characters (eg " and : )?
--
Problem reports: http://cyg
Sent from my iPhone
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
tually have to hit "shift" before
> hitting the 5 key to get ctrl+b %, same for ".
>
> I realized this after changing key bindings for horizontal and
> vertical spit to | and -. When | didn't work but the other did I had a
> suspicion so I tried \. The light bulb glowe
So now I feel like a total dork. Really.
I reinstalled tmux and everything worked *except screen splitting or,
as it turns out, anything that was a key combination requiring
reaching a shifted key. Yeah, you actually have to hit "shift" before
hitting the 5 key to get ctrl+b %, same
My problem isn't with redefining bindings. It's worse, as I indicated.
But thanks.
Other than starting a tmux session, nothing else works. It's of as much
use as a standard terminal.
I've pretty much pulled the plug on it since I can't get it work on my
Cygwin install.
--
Problem reports:
I'm running tmux fine in mintty (64 bit version though). I have the
terminal type in mintty set to xterm256-color. I have this in my
.tmux.conf, though I don't think any of it is necessarily relevant in
your situation.
# Set prefix key to C-a
set -g prefix C-a
unbind C-b
bind C-a s
I searched Google.
I looked at sourceforge tickets http://sourceforge.net/p/tmux/tickets/
I've read this Cygwin tmux announcement:
https://cygwin.com/ml/cygwin-apps/2014-06/msg00018.html
I've reinstalled tmux with cygwin-x86 installer.
I've had no luck.
ctrl+b "command&qu
On Tue, Apr 08, 2014 at 07:46:26PM +0200, Corinna Vinschen wrote:
>What he says.
>
>And just if it's still not clear, despite the fact that WJM, we would
>*love* to get more patches. It doesn't mean your patch will go in
>without scrutinizing and maybe we ask for changes, but we're always open
>to
> The whole POINT of this thread was that we want patches.
You've just killed that point, alright. The change I was about, was merely a
word-long (another keyword to be added),
the discussion that sparkled was just despicable.
The response was so earful, with profanities and teaching me (?) leg
On Apr 8 12:49, Christopher Faylor wrote:
> On Tue, Apr 08, 2014 at 12:27:26PM -0400, Tim Prince wrote:
> >
> >On 4/8/2014 11:21 AM, Christopher Faylor wrote:
> >> Non-sarcastic translation: Don't expect us to know about your s**t. We
> >> have standard expectations for this free software project
On Tue, Apr 08, 2014 at 12:27:26PM -0400, Tim Prince wrote:
>
>On 4/8/2014 11:21 AM, Christopher Faylor wrote:
>> Non-sarcastic translation: Don't expect us to know about your s**t. We
>> have standard expectations for this free software project and the
>> expectations are do not include keeping
On 4/8/2014 11:21 AM, Christopher Faylor wrote:
Non-sarcastic translation: Don't expect us to know about your s**t. We
have standard expectations for this free software project and the
expectations are do not include keeping a mental map of the rules of
every email domain that sends messages h
On Tue, Apr 08, 2014 at 05:50:26PM +0200, Corinna Vinschen wrote:
>On Apr 8 16:44, Adam Dinwoodie wrote:
>> On Tue, Apr 08, 2014 at 01:34:21PM +, Lavrentiev, Anton (NIH/NLM/NCBI)
>> [C] wrote:
>> > > He's a contractor for the US Government. That makes things complicated
>> > > and sometimes
On Apr 8 16:44, Adam Dinwoodie wrote:
> On Tue, Apr 08, 2014 at 01:34:21PM +, Lavrentiev, Anton (NIH/NLM/NCBI)
> [C] wrote:
> > > He's a contractor for the US Government. That makes things complicated
> > > and sometimes seemingly nonsensical.
> >
> > Thanks, Barry.
> >
> > A patch (howev
On Tue, Apr 08, 2014 at 01:34:21PM +, Lavrentiev, Anton (NIH/NLM/NCBI) [C]
wrote:
> > He's a contractor for the US Government. That makes things complicated and
> > sometimes seemingly nonsensical.
>
> Thanks, Barry.
>
> A patch (however small) means code, all my code must under the Public
On Tue, Apr 08, 2014 at 01:34:21PM +, Lavrentiev, Anton (NIH/NLM/NCBI) [C]
wrote:
>>He's a contractor for the US Government. That makes things complicated
>>and sometimes seemingly nonsensical.
>
>A patch (however small) means code, all my code must under the Public
>Domain Notice (and which
> He's a contractor for the US Government. That makes things complicated and
> sometimes seemingly nonsensical.
Thanks, Barry.
A patch (however small) means code, all my code must under the Public Domain
Notice (and which can't be GPL'd). Thus, our legal
office does not allow us contributing
Corinna Vinschen sent the following at Tuesday, April 08, 2014 5:01 AM
>On Apr 8 03:30, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>>> I cannot supply patches for you guys because of the GPL.
>
>What on earth keeps you from sending patches to a GPLed project while at
>the same time using it is no
On Apr 8 03:30, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > Nah. Maybe we'll have something when the Singularity finally occurs.
>
> I cannot supply patches for you guys because of the GPL.
What on earth keeps you from sending patches to a GPLed project while at
the same time using it is no
> Nah. Maybe we'll have something when the Singularity finally occurs.
I cannot supply patches for you guys because of the GPL. No need to be
sarcastic all the time --
for the project lead it does not sound witty.
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: http://cygw
es a handle to a process, such as the wait functions, provided the
>appropriate access rights were requested.
>
>
>http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880%28v=vs.85%29.aspx
If only there was some way to programatically supply a change in source
code from part
Hello,
It looks like in order to effectively kill the process by Windows means (i.e.
what Cygwin "kill -f" is supposed to do),
the process handle must be obtained with the SYNCHRONIZE right (in addition to
PROCESS_TERMINATE), otherwise
WaitForSingleObject() fails with code 5, permission denied (
On Mar 29 04:42, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> Hi,
>
> I need to kill a process in a way that CYGWIN's own kill utility does
> with an option -f, and for that, given CYGWIN's PID, I need to figure
> out native Windows PID of the victim.
>
> kill does basically the following (I sim
Hi,
I need to kill a process in a way that CYGWIN's own kill utility does
with an option -f, and for that, given CYGWIN's PID, I need to figure
out native Windows PID of the victim.
kill does basically the following (I simplified):
p = (external_pinfo *) cygwin_internal (CW_GETPINFO_FULL, pid);
fferently.
As for the difference itself, here's what happened:
The gawk maintainer was unhappy with how regex ranges worked when using
locales other than the C locale. So he implemented a change to regex
which he called "rational ranges". The idea being, that something like
[b-d]
#x27;m using US English Windows 7.
> >
> > LANG = 'en_US.UTF-8'
> >
> > I get the same result:
> >
> > $ echo abcdeABCDE | sed -e 's/[B-D]/_/g'
> > ab__eA___E
> >
> > BUT:
> >
> > $ echo abcdeABCDE | LANG=C sed
This only happens if you are on the GNU system, using GNU libc's
regular expression matcher instead of compiling the one supplied
with GNU sed. In a Danish locale, for example, the regular
expression `^[a-z]$' matches the string `aa', because this is a
singl
F-8'
>
> I get the same result:
>
> $ echo abcdeABCDE | sed -e 's/[B-D]/_/g'
> ab__eA___E
>
> BUT:
>
> $ echo abcdeABCDE | LANG=C sed 's/[B-D]/_/g'
> abcdeA___E
>
> This is very weird, indeed.
>
> OTOH, in Linux I have the same
> The character ordering is based on the default Windows ordering for the
> locale, and that's dictionary ordering, apparently.
Ah, I see what you meant here. There's an elaborated explanation:
http://www.gnu.org/software/gawk/manual/html_node/Ranges-and-Locales.html
Anton Lavrentiev
Contractor
> Your locale is zh_CN.UTF-8. What you're expecting is only guaranteed
> in the C locale:
I'm not quite sure it applies here. I'm using US English Windows 7.
LANG = 'en_US.UTF-8'
I get the same result:
$ echo abcdeABCDE | sed -e 's/[B-D]/_/g'
ab__eA_
On Jun 25 22:37, Atry wrote:
> [...]
> $ echo abcdeABCDE | sed -e 's/[B-D]/_/g'
> ab__eA___E
Your locale is zh_CN.UTF-8. What you're expecting is only guaranteed in
the C locale:
$ LANG=C && echo abcdeABCDE | sed -e 's/[B-D]/_/g'
The characte
OK
libtasn1_3 2.14-1 OK
libusb-win32 1.2.5.0-1 OK
libwind0 1.5.2-3 OK
libwrap0 7.6-21 OK
libxml2 2.8.0-1OK
libxslt 1.1.27-
On May 17 21:19, Corinna Vinschen wrote:
> On May 15 11:39, Kazuhiro Fujieda wrote:
> > >>> On Fri, 14 May 2010 21:27:16 +0200
> > >>> Corinna Vinschen said:
> >
> > >> It should return "5\u6708" in Japanese and "5\uc6d4" in
> > >> Korea. MSDN in Japanese describes so. It, however, returns "5"
> >
On May 15 11:39, Kazuhiro Fujieda wrote:
> >>> On Fri, 14 May 2010 21:27:16 +0200
> >>> Corinna Vinschen said:
>
> >> It should return "5\u6708" in Japanese and "5\uc6d4" in
> >> Korea. MSDN in Japanese describes so. It, however, returns "5"
> >> in both locales.
> >
> > Can you please tell us the
>>> On Fri, 14 May 2010 21:27:16 +0200
>>> Corinna Vinschen said:
>> It should return "5\u6708" in Japanese and "5\uc6d4" in
>> Korea. MSDN in Japanese describes so. It, however, returns "5"
>> in both locales.
>
> Can you please tell us the number of the knowledge base article saying
> so?
There
On May 14 10:55, Kazuhiro Fujieda wrote:
> >>> On Wed, 12 May 2010 17:31:18 +0200
> >>> Corinna Vinschen said:
>
> > No, that's not broken, even if it seems so. Cygwin fetches the
> > localized strings from the underlying OS, not from a Cygwin-specific
> > locale database. What you see as resul
>>> On Wed, 12 May 2010 17:31:18 +0200
>>> Corinna Vinschen said:
> No, that's not broken, even if it seems so. Cygwin fetches the
> localized strings from the underlying OS, not from a Cygwin-specific
> locale database. What you see as results above is what *Windows*
> returns for the full and
On May 12 22:27, IWAMURO Motonori wrote:
> Hi.
>
> strftime %b is broken on ja_JP locale on cygwin-1.7.5-1.
> [...]
> - result on Cygwin: [5月][5] - missing suffix "月" (U+6708).
> - result on Debian lenny: [5月][ 5月]
No, that's not broken, even if it seems so. Cyg
Hi.
strftime %b is broken on ja_JP locale on cygwin-1.7.5-1.
[monthtest.c]
#include
#include
#include
int main(void) {
time_t now;
struct tm *tm;
char buffer[4096];
setlocale(LC_ALL, "ja_JP.UTF-8");
time(&now);
tm = localtime(&now);
strftime(buffer, si
ow...@cygwin.com] On Behalf Of
Jeremy Bopp
Sent: Wednesday, May 05, 2010 1:08 PM
To: cygwin@cygwin.com
Subject: Re: 1.7.1: Replacement for mount -f -u -b c: /
On 5/5/2010 2:57 PM, Mathew Shember wrote:
> In the previous release, some of our engineers would change:
>
> /cygwin/c/export/h
On 5/5/2010 3:08 PM, Jeremy Bopp wrote:
> On 5/5/2010 2:57 PM, Mathew Shember wrote:
>> In the previous release, some of our engineers would change:
>>
>> /cygwin/c/export/home/
>>
>> To
>>
>> /export/home
>>
>> To eliminate the "/c&q
On 5/5/2010 2:57 PM, Mathew Shember wrote:
> In the previous release, some of our engineers would change:
>
> /cygwin/c/export/home/
>
> To
>
> /export/home
>
> To eliminate the "/c" they would use
>
> Mount -f -u -b c: /
>
> This no lon
In the previous release, some of our engineers would change:
/cygwin/c/export/home/
To
/export/home
To eliminate the "/c" they would use
Mount -f -u -b c: /
This no longer works and I haven't figured out a work around.
Tried playing with fstab with no luck.
Thanks
Mat
On Wed, Nov 25, 2009 at 10:33:53AM -0500, Buchbinder, Barry (NIH/NIAID) [E]
wrote:
>aputerguy sent the following at Tuesday, November 24, 2009 5:10 PM
>>Seriously, there are times to use Perl and times not to... But
>>launching perl seems a bit of overkill when I just have to do a simple
>>match
aputerguy sent the following at Tuesday, November 24, 2009 5:10 PM
>
> Seriously, there are times to use Perl and times not to... But launching
> perl seems a bit of overkill when I just have to do a simple match in a
>.bashrc script or when I need a small shell script wrapper.
Looking at the man
On Nov 24 17:23, Christopher Faylor wrote:
> On Tue, Nov 24, 2009 at 10:18:27PM +, Eric Blake wrote:
> >So, in true open source fashion, why not write a patch that teaches cygwin's
> >regex(3) implementation that \b is a synonym to [[:<:][:>:]]?
> >[...]
&
her direction of
word boundary (for shame). So, modulo the difference in the number of
subexpressions, the closest representation of \b becomes:
([[:<:]]|[[:>:]])
and an expression to match words that either end in a or begin in b would be:
$ [[ ' b ' =~ ([a ]([[:<:]]|[[:>:
aputerguy schrieb:
Hugh Myers:
This might come across as slightly smart-assed, but if you wrote your
script in Perl, you wouldn't have the platform problem, nor the
word-boundary problem. True you would have a Perl problem, but that
would still be several orders of magnitude easier than tryi
an extension, compatible with but
> not specified by POSIX 1003.2, and should be used with caution in soft-
> ware intended to be portable to other systems.
>
>>
>> So, now I have the frustrating situation where \\b works in Linux but not in
>> Cygwin while [[
ware intended to be portable to other systems.
>
> So, now I have the frustrating situation where \\b works in Linux but not in
> Cygwin while [[:<:]] works in Cygwin but not in Linux.
So, in true open source fashion, why not write a patch that teaches cygwin's
regex(3) impleme
What I have often done in a case like this is:
Add the separator (space in this case) at each end of the list.
So, if the initial string is "101 203 455" I turn that into
" 101 203 455 ".
LIST=" ${LIST} "
Then I match the desired string, also surrounded by spaces,
like this:
[ -z "${LIST##* ${
Hugh Myers:
> This might come across as slightly smart-assed, but if you wrote your
> script in Perl, you wouldn't have the platform problem, nor the
> word-boundary problem. True you would have a Perl problem, but that
> would still be several orders of magnitude easier than trying to have
> Li
" or "boundary" - neither of which are used in this
> context.
>
> HOWEVER, this solution while sweet for cygwin-bash, has the CONVERSE
> PROBLEM.
> Apparently, the special strings [[:<:]] and [[:>:]] are not recognized under
> Linux regex(7) - they give return co
Apparently, the special strings [[:<:]] and [[:>:]] are not recognized under
Linux regex(7) - they give return code 2.
So, now I have the frustrating situation where \\b works in Linux but not in
Cygwin while [[:<:]] works in Cygwin but not in Linux.
BTW, both regex(7) pages even im
aputerguy wrote:
> OK - I think I found the answer which is that \b is a GNU extension not
> recognized in cygwin.
>
> So, I guess the question now is there an alternative way of recognizing word
> boundaries?
Bash man page for '~=' refers to man regex(3) which ref
Just for the record, the following works:
[[ "$proc" =~ (^|[^0-9])$foo([^0-9]|$) ]] ; echo $?
where I use $foo to store the process number I am trying to match against
--
View this message in context:
http://old.nabble.com/Cygwin-bash-regexp-matching-doesn%27t-treat-%22%5Cb%22-properly-tp2650
aputerguy writes:
> Perhaps, I could try adding white space as in
> [[ " $proc " =~ " 456 " ]]
> but not sure if that will always work.
Actually it doesn't work.
I guess I could try to try to prepend/postpend something like an 'x' to each
element of $proc, but that seems really kludgey
--
View
OK - I think I found the answer which is that \b is a GNU extension not
recognized in cygwin.
So, I guess the question now is there an alternative way of recognizing word
boundaries?
In particular, I am trying to match a process id where $proc is a list of
one or more processes (awk'd fr
The following behavior differs between Cygwin bash (both versions 3.2.39,
3.2.49) and Fedora/Linux bash (both versions 3.2.33 and 4.0.33):
$ [[ "foo" =~ \\bfoo\\b ]]; echo $?
Cygwin:
1
Linux:
0
Cygwin returns 0 only if I remove the \\b from before and after the word
'foo
lloc() + memcpy()
> if you maintain the char* name and size_t buf_len in
> the argv_iterator struct, then you can return pointers
> to the orig data, and remove the need to free() from the
> users of argv_iter().
Good suggestion! Thanks.
diff --git a/gl/lib/argv-iter.c b/gl/lib/argv-iter.c
Jim Meyering wrote:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>> Jim Meyering wrote:
>>> Subject: [PATCH 1/2] argv-iter: new module
>>>
>>> * gl/lib/argv-iter.h: New file.
>>> * gl/lib/argv-iter.c: New file.
>>> * gl/modules/argv-iter: New file.
>> Very useful module!
>>
>> I see that --files0-fro
Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> Subject: [PATCH 1/2] argv-iter: new module
>>
>> * gl/lib/argv-iter.h: New file.
>> * gl/lib/argv-iter.c: New file.
>> * gl/modules/argv-iter: New file.
>
> Very useful module!
>
> I see that --files0-from was added to `du` in Mar 20
Jim Meyering wrote:
> Subject: [PATCH 1/2] argv-iter: new module
>
> * gl/lib/argv-iter.h: New file.
> * gl/lib/argv-iter.c: New file.
> * gl/modules/argv-iter: New file.
Very useful module!
I see that --files0-from was added to `du` in Mar 2004,
so it's a nice solution to this 4 year old issue.
via standard input,
>>> to a command-line that looks like:
>>>
>>> du -b --files0-from=-
>
> du's --files0-from option reads the entire list of
> file names into memory before processing the first name.
[By the way, this flaw affects wc and sort, too, since
gt;> to a command-line that looks like:
>>
>> du -b --files0-from=-
Thank you for the report.
(thanks, Erik for the Cc)
du's --files0-from option reads the entire list of
file names into memory before processing the first name.
That bug should be fixed very quickly ;-)
--
Unsub
Eric Blake wrote:
> [adding the upstream coreutils list]
>
> According to Barry Kelly on 11/23/2008 6:24 AM:
> > I have a problem with du running out of memory.
> >
> > I'm feeding it a list of null-separated file names via standard input,
> > to a command-
e that looks like:
>
> du -b --files0-from=-
>
> The problem is that when du is run in this way, it leaks memory like a
> sieve. I feed it about 4.7 million paths but eventually it falls over as
> it hits the 32-bit address space limit.
That's because du must keep track of wh
I have a problem with du running out of memory.
I'm feeding it a list of null-separated file names via standard input,
to a command-line that looks like:
du -b --files0-from=-
The problem is that when du is run in this way, it leaks memory like a
sieve. I feed it about 4.7 million path
On Sat, Aug 30, 2008 at 10:34:36AM -0700, Stephan Mueller wrote:
>Creating a test batch file that echos %1 etc and %* is pretty trivial
>to create. In mine, I tend to do
>@echo echoing percent-n
>@echo .%1. .%2. .%3. .%4. .%5. .%6. .%7. .%8. .%9.
>and similarly for %* -- the dots w
--Original Message-
From: Stephan Mueller [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 30, 2008 1:35 PM
To: Phil Smith; Jay; cygwin@cygwin.com
Subject: RE: Probably stupid make question (cmd a=b)
Creating a test batch file that echos %1 etc and %* is pretty trivial to
create. In mine, I
no-space-in-name location.
stephan();
-Original Message-
From: Phil Smith [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 30, 2008 8:57 AM
To: Jay; cygwin@cygwin.com; Stephan Mueller
Subject: RE: Probably stupid make question (cmd a=b)
Thanks for the good ideas.
The Makefile is generated by CMake, and
ge-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jay
Sent: Saturday, August 30, 2008 10:48 AM
To: cygwin@cygwin.com; Phil Smith; [EMAIL PROTECTED]
Subject: RE: Probably stupid make question (cmd a=b)
continuing somewhat off topic:
> Probably stupid make question
> 14
@echo 1 is %1
@echo 2 is %2
D:\>.\2.cmd a=b
1 is a
2 is b
D:\>.\2.cmd "a=b"
1 is "a=b"
2 is
I think tilde is how to strip quotes:
echo 1 is %~1
echo 2 is %~2
to echo without quotes
echo 1 is "%~1"
Svend Sorensen wrote:
ls has a recursive flag for ls (-R), but the find command may be more
appropriate for scripting.
Thank you!!!
Ignazio
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://
fergus wrote:
find .
Exactly!!! Thank you very much!!!
Ignazio
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
What about something along the lines of these examples?
find .
find . | sort
find /usr/local | sort
also
find . -type d # to list just directories
find . -type f # to list just files
find . -type l # to list just links
Any use?
Fergu
On 2/15/07, Ignazio Di Napoli wrote:
I'm newbie with Cygwin. Looking through ls option, I didn't find
anything to list then names of all files in the directory and all
subdirectories, like dir /b /s does. Since it can be very useful in bash
scripts, there must be some way. Right now I
Hi everyone.
I'm newbie with Cygwin. Looking through ls option, I didn't find
anything to list then names of all files in the directory and all
subdirectories, like dir /b /s does. Since it can be very useful in bash
scripts, there must be some way. Right now I've done a recu
1 - 100 of 152 matches
Mail list logo
