Hi David,
On Apr 20 08:43, David Allsopp via Cygwin wrote:
> Hi Corinna,
>
> > On Apr 9 22:38, Corinna Vinschen via Cygwin wrote:
> > > On Apr 3 16:53, David Allsopp via Cygwin wrote:
> > > > I have what appears to be a regression in Cygwin 3.5.0 which, owing to
> > > > a CI system lagging behi
On 2024-04-20 06:31, Eliot Moss via Cygwin wrote:
On 4/20/2024 8:12 AM, enrique--- via Cygwin wrote:
Hello,
I am trying to install a service manually in an attempt to understand why
cron-config did not work for me.
So, I did this:
$ net stop cron
Tjenesten Cron daemon stopper .
Tjenesten C
Hi Corinna,
> On Apr 9 22:38, Corinna Vinschen via Cygwin wrote:
> > On Apr 3 16:53, David Allsopp via Cygwin wrote:
> > > I have what appears to be a regression in Cygwin 3.5.0 which, owing to
> > > a CI system lagging behind, we've only just discovered.
> > > [...]
> > > $ ./t.exe 'C:\Devel\🐫р
Hi David,
On Apr 9 22:38, Corinna Vinschen via Cygwin wrote:
> On Apr 3 16:53, David Allsopp via Cygwin wrote:
> > I have what appears to be a regression in Cygwin 3.5.0 which, owing to
> > a CI system lagging behind, we've only just discovered.
> > [...]
> > $ ./t.exe 'C:\Devel\🐫реализация-ming
Hi David,
On Apr 3 16:53, David Allsopp via Cygwin wrote:
> I have what appears to be a regression in Cygwin 3.5.0 which, owing to
> a CI system lagging behind, we've only just discovered.
> [...]
> $ ./t.exe 'C:\Devel\🐫реализация-mingw64\flexdll\flexdll_mingw64.o'
> stat: cannot stat
> '"C:\Deve
I have what appears to be a regression in Cygwin 3.5.0 which, owing to
a CI system lagging behind, we've only just discovered.
In order to torture our Unicode support, OCaml's Windows CI compiles
its sources in C:\projects\🐫реализация-mingw64 (that's a directory
under C:\projects with the camel em
On 2020/11/12 08:10, Ilya Basin via Cygwin wrote:
Hi.
When I launch a Cygwin program from a native Windows program and an argument in
the command line string is quoted and contains national characters then the
Cygwin program behaves as if double quotes were part of the program argument.
This ha
Hi.
When I launch a Cygwin program from a native Windows program and an argument in
the command line string is quoted and contains national characters then the
Cygwin program behaves as if double quotes were part of the program argument.
This happens if I don't explicitly set LC_ALL or if I set L
George Prekas via cygwin writes:
> More specifically the flag --enable-backwards-compatibility enables
> the backward compatible expansion of dollar sign expressions to
> command line arguments in gnuplot source files. Is there any specific
> reason that Cygwin chooses to enable this
Cygwin
and Ubuntu:
ubuntu$ echo 'print "$0"' > x
ubuntu$ gnuplot -c x 1
$0
cygwin$ echo 'print "$0"' > x
cygwin$ gnuplot -c x 1
1
More specifically the flag --enable-backwards-compatibility enables the
backward compatible expansion of dollar sign exp
Problem: setup.exe ignores unrecognized command-line arguments silently.
For example: the command line "setup.exe -P p7zip curl" installs p7zip
but not curl.
Suggestion: Make it print a warning when it encounters an unrecognized
command-line argument. So: "setup.exe -P p7z
Greetings, OwN-3m-All!
> Thanks guys. That was it. I decided to remove the trailing slash for
> my purposes.
> set WD=%~dp0
> set WD=%WD:~0,-1%
> It's working now!
Alternatively, you could translate backslashes to regular slashes. Should work
too.
SETLOCAL ENABLEEXTENSIONS
SET CWD=%CD:\=/%
Thanks guys. That was it. I decided to remove the trailing slash for
my purposes.
set WD=%~dp0
set WD=%WD:~0,-1%
It's working now!
On Mon, Nov 14, 2016 at 12:23 PM, Brian Inglis
wrote:
> On 2016-11-14 07:43, Gerrit Haase wrote:
>>
>> 2016-11-13 23:19 GMT+01:00 OwN-3m-All wrote:
>>>
>>> I'd li
On 2016-11-14 07:43, Gerrit Haase wrote:
2016-11-13 23:19 GMT+01:00 OwN-3m-All wrote:
I'd like to automate Cygwin installation, but I don't want to rule
out the possibility that a path with a space will not be used.
You'll get a warning from Setup: it is strongly recommended, to use a
root pat
> Try adding a dot:
>
> set WD=%~dp0
> echo "%WD%."
> "setup-x86_64.exe" --root "%WD%." --local-package-dir "%WD%."
> pause
or
set WD=%~dp0.
...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.h
2016-11-13 23:19 GMT+01:00 OwN-3m-All wrote:
> cd "C:\test\with space"
> set WD=%~dp0
> echo "%WD%cygTemp"
> "setup-x86_64.exe" --root "%WD%" --local-package-dir "%WD%cygTemp"
> pause
>
The problem is this trailing backslash in the directory name.
D:\temp\Neuer Ordner\cygwinpkg>setup_script.bat
Is there a way to pass in paths that contain a space in the --root and
--local-package-dir Cygwin command-line arguments? Everything I've
tried doesn't work.
Here's a sample batch script to reproduce the issue (create a
directory with a space in it, copy Cygwin setup exe, and
ithin a quoted parameter as an escaped single backslash), and quite clearly
not MSDN's (treating \\ as two backslash characters because it's no followed by
a double-quote). As an aside, if you have CYGWIN=noglob, you will actually get
the same output as the native Windows case with two
t; > Yes, but the question still remains what that rudimentary quoting is -
> > i.e.
> > > I can see how to quote spaces which appear in elements of argv, but I
> > > cannot see how to quote double quotes!
> >
> > This should help:
> > https://blogs.m
Marco Atzeri wrote:
> On 09/05/2016 17:49, David Allsopp wrote:
> > Marco Atzeri wrote:
> >>
> >> Ultimate overview of MS escape howto :
> >>
> >> https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04
> >> /23/e veryone-quotes-c
On 09/05/2016 17:49, David Allsopp wrote:
Marco Atzeri wrote:
Ultimate overview of MS escape howto :
https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/e
veryone-quotes-command-line-arguments-the-wrong-way/
This is a great article (which I'd not come across b
Marco Atzeri wrote:
>
> Ultimate overview of MS escape howto :
>
> https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/e
> veryone-quotes-command-line-arguments-the-wrong-way/
This is a great article (which I'd not come across before), but this re
Hi!
Peter Rosin wrote:
> I think cygwin emulates posix shell style command line parsing when
> invoked from a Win32 process (like you do). So, try single quotes:
>
> commandLine = "callee.exe \"@\"te\"\n\"st fo@o bar\" \"baz baz '*'
> '\"\\'\"'";
>
> I get this (w/o noglob):
>
> argc = 7
> argv
can see how to quote spaces which appear in elements of argv, but I
> > cannot see how to quote double quotes!
>
> This should help:
> https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/e
> veryone-quotes-command-line-arguments-the-wrong-way/
This provides docum
> see how to quote double quotes!
This should help:
https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/
My line of thought is that Cygwin can't get anything which Windows can't send
it. So the first step
s the arguments for the Cygwin process
in an array, but Windows internally requires a single command line
string (which is not in any related to Cmd).
Ultimate overview of MS escape howto :
https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-argu
Hi!
On 2016-05-07 09:45, David Allsopp wrote:
> Andrey Repin wrote:
>> Greetings, David Allsopp!
>
> And greetings to you, too!
>
>
>
>>> I'm not using cmd, or any shell for that matter (that's actually the
>>> point) - I am in a native Win32 process invoking a Cygwin process
>>> directly usi
Andrey Repin wrote:
> Greetings, David Allsopp!
And greetings to you, too!
> > I'm not using cmd, or any shell for that matter (that's actually the
> > point) - I am in a native Win32 process invoking a Cygwin process
> > directly using the Windows API's CreateProcess call. As it happens,
> >
Greetings, David Allsopp!
> [With apologies if threading is broken; I erroneously thought as the list
> was not subscriber-only that replies would use reply-all and so wasn't
> subscribed]
As long as your mail client is fine, you're fine.
> I'm not using cmd, or any shell for that matter (that'
On Fri, May 6, 2016 at 4:03 AM, David Allsopp wrote:
>
> [With apologies if threading is broken; I erroneously thought as
> the list was not subscriber-only that replies would use reply-all
> and so wasn't subscribed]
Didn't break for me, though that might be google's threading in gmail
rather tha
[With apologies if threading is broken; I erroneously thought as the list was
not subscriber-only that replies would use reply-all and so wasn't subscribed]
On Thu, May 5, 2016 at 06:47 PM, Erik Soderquist wrote:
> On Thu, May 5, 2016 at 11:24 AM, David Allsopp wrote:
> >
> > I am trying to work
On Thu, May 5, 2016 at 11:24 AM, David Allsopp wrote:
>
> I am trying to work out the precise details for character escaping when
> starting a Cygwin process from a native (i.e. non-Cygwin) Windows process.
> For example:
>
> argv[0] = "foo"
> argv[1] = "bar baz"
>
> then the resulting command
I am trying to work out the precise details for character escaping when
starting a Cygwin process from a native (i.e. non-Cygwin) Windows process.
I have an array of command line arguments which I want passed verbatim to
the process, as though it were invoked using execv, with no globbing to take
On Mon, May 20, 2013 at 10:32:07AM +0200, AZ 9901 wrote:
>Do you think ps command could be corrected / improved to display
>"myscript" (script's name according to the example above) and/or
>command line arguments ?
We have no plans on modifying Cygwin's ps program.
-
hey are not allowed
>> to access /proc//cmdline, /proc//stat etc... of other users...
>>
>> This is why "ps -ef" giving command line arguments would be really perfect !
>
> I also just tested a workaround using the bash builtin command "exec".
> I
Le 7 mai 2013 à 16:39, Warren Young a écrit :
> Your script will also fail on most FreeBSD machines, for example. On
> FreeBSD, there is a kernel build option that is often set which prevents user
> space from *ever* seeing command line options. It's a security feature,
> since there are all
On 5/7/2013 02:46, AZ 9901 wrote:
This script uses "ps -ef" in particular to list all its instances.
Any script that relies on 'ps' output parsing is probably unportable
from the get-go.
Your script will also fail on most FreeBSD machines, for example. On
FreeBSD, there is a kernel build
0 10:21 ?00:00:00 /bin/bash ./myscript.sh
> marty 20330 20342 0 10:23 ?00:00:00 /bin/bash ./myscript.sh
> dudul 20339 20363 0 10:25 ?00:00:00 /bin/bash ./myscript.sh
> Perfect !
>
> With Cygwin, "ps -ef" does not give command line argum
2 0 10:23 ?00:00:00 /bin/bash ./myscript.sh
dudul 20339 20363 0 10:25 ?00:00:00 /bin/bash ./myscript.sh
Perfect !
With Cygwin, "ps -ef" does not give command line arguments, so the script can't
list its instances.
I was thinking about using procps or printing /proc
On Fri, Nov 02, 2012 at 10:54:25AM -0400, Eliot Moss wrote:
>On 11/2/2012 10:32 AM, Andrew DeFaria wrote:
>>On 11/02/2012 05:36 AM, Earnie Boyd wrote:
>
>Can we declare an end to the philosophical flames on how to write uses
>of parameters in bash scripts, please?
I know that I, of all people, sho
On 11/2/2012 10:32 AM, Andrew DeFaria wrote:
On 11/02/2012 05:36 AM, Earnie Boyd wrote:
Can we declare an end to the philosophical flames
on how to write uses of parameters in bash scripts,
please?
Maybe if we're friendly enough the OP will actually
share what the real problem was and we can o
On 11/02/2012 05:36 AM, Earnie Boyd wrote:
YMMV when it comes time for maintenance by someone other than the code creator.
Consistency helps reduce cost and reducing company cost helps increase my pay
check.
I disagree. A [emphasis on] *foolish* consistency doesn't do anything to
reduce cost.
On Thu, Nov 1, 2012 at 4:48 PM, Andrew DeFaria wrote:
> On 11/1/2012 10:54 AM, Brian Wilson wrote:
>>
>> I got in the habbit of always using the "{}" (even if they aren't
>> absolutely necessary) to avoid such issues on general principal.
>
> I don't think it's conducive to productivity to constant
On 11/1/2012 10:54 AM, Brian Wilson wrote:
I got in the habbit of always using the "{}" (even if they aren't
absolutely necessary) to avoid such issues on general principal.
I don't think it's conducive to productivity to constantly type things
that aren't needed for the simple sake of consisten
On Thu, Nov 1, 2012 at 1:54 PM, Brian Wilson wrote:
>> > % >${1}, ${2}, etc. Also, you may want to read up on the getopts
>> > command as a % >way to process command line arguments. % Technically,
>> > the {}'s are not needed. You can access them with $1, $2,
> > % >${1}, ${2}, etc. Also, you may want to read up on the getopts
> > command as a % >way to process command line arguments. % Technically,
> > the {}'s are not needed. You can access them with $1, $2, ... %
> > "/path/to/$1.save/dir"
On 10/31/2012 12:40 PM, David T-G wrote:
Andrew, et al --
...and then Andrew DeFaria said...
%
% On 10/31/2012 11:23 AM, Brian Wilson wrote:
...
% >${1}, ${2}, etc. Also, you may want to read up on the getopts command as a
% >way to process command line arguments.
% Technically, the {}
Andrew, et al --
...and then Andrew DeFaria said...
%
% On 10/31/2012 11:23 AM, Brian Wilson wrote:
...
% >${1}, ${2}, etc. Also, you may want to read up on the getopts command as a
% >way to process command line arguments.
% Technically, the {}'s are not needed. You can access them
Also, you may want to read up on the getopts command as a
way to process command line arguments.
Technically, the {}'s are not needed. You can access them with $1, $2,
etc. Most special characters sever as delimiters too so you can refer to
them as "This the $1 parameter" or even
ts command as a
way to process command line arguments.
Sincerely,
Brian S. Wilson
> In cygwin, is it possible to pass arguments to a shell script file?
> I have installed the latest cygwin with default packages.
I assume you are attempting to script in Bash, therefore I suggest reading:
http://tldp.org/LDP/abs/html/
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.
On 10/30/2012 10:20 AM, chesschi wrote:
> In cygwin, is it possible to pass arguments to a shell script file? I have
> installed the latest cygwin with default packages. I found that argument
> zero ($0) is correct. However, the number of arguments always returns zero
> ($#= 0) and $1, $2... are
idea? Thanks a lot!
--
View this message in context:
http://cygwin.1069669.n5.nabble.com/Command-line-arguments-tp94081.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq
From: Adam Dinwoodie
>John Wiersba wrote:
>>P.S. I don't know why, but my reply kept getting rejected as spam by
>>cygwin.org's filters, even though I was using yahoo's "plain text" mode:
>>
>> Remote host said: 552 spam score exceeded threshold (#5.6.1) [BODY]
>
>See http://cygwin.com/ml/#spam
ned.
- Barry
Disclaimer: Statements made herein are not made on behalf of NIAID.
From: "Buchbinder, Barry (NIH/NIAID) [E]"
Sent: Sunday, August 5, 2012 2:38 PM
Subject: RE: Cygstart bug: doesn't keep command line arguments intact
John Wiersb
John Wiersba wrote:
>P.S. I don't know why, but my reply kept getting rejected as spam by
>cygwin.org's filters, even though I was using yahoo's "plain text" mode:
>
> Remote host said: 552 spam score exceeded threshold (#5.6.1) [BODY]
See http://cygwin.com/ml/#spam for how to avoid that.
Also,
Thanks for your reply, Barry. Yes, it seems that way to me, too. But that
seems wrong. I would think that cygstart should pass arg1 as arg1 to the
specified command (winword.exe in my example). That's certainly the way it
works in the unix/linux world and cygstart should be considered as an
John Wiersba wrote August 03, 2012 3:18 PM
>Calling /c/program\ files/microsoft\ office/office12/winword.exe
>"a b c.doc" works.
>Calling cygstart /c/program\ files/microsoft\ office/office12/winword.exe "a b
>c.doc" tries to open a.doc, b.doc, and c.doc.
In the first, bash strips t
Calling /c/program\ files/microsoft\ office/office12/winword.exe
"a b c.doc" works.
Calling cygstart /c/program\ files/microsoft\ office/office12/winword.exe "a b
c.doc" tries to open a.doc, b.doc, and c.doc.
I couldn't find this reported in the mailing list archives.
--
Problem
Dave Korn wrote:
On 07/04/2010 00:24, Robrecht Dewaele wrote:
$ LDFLAGS=-lpopt make options
Only put flags in LDFLAGS. Put libs in LDLIBS. The default rule is
%: %.c
# commands to execute (built-in):
$(LINK.c) $^ $(LOADLIBES) $(LDLIBS) -o $@
and LINK.c embeds
On 2010-04-06 23:24Z, Robrecht Dewaele wrote:
>
> # Using builtin make rules and LDFLAGS seems to yield an incorrect
> order of arguments for cc.
> $ LDFLAGS=-lpopt make options
http://www.gnu.org/software/make/manual/html_node/Catalogue-of-Rules.html#Catalogue-of-Rules
| The precise command
On 07/04/2010 00:24, Robrecht Dewaele wrote:
> $ LDFLAGS=-lpopt make options
Only put flags in LDFLAGS. Put libs in LDLIBS. The default rule is
> %: %.c
> # commands to execute (built-in):
> $(LINK.c) $^ $(LOADLIBES) $(LDLIBS) -o $@
and LINK.c embeds LDFLAGS. On ELF platforms where
Hello everyone,
I'm not sure whether this is a make or a cygwin issue, but it has
occured to me only on cygwin, so I thought to ask here first.
To illustrate my problem, I have written a little testcase (options.c)
which uses libpopt and illustrate how to reproduce the behaviour at the
bottom
On Fri, Jan 22, 2010 at 03:07:10PM -0800, Brolin Empey wrote:
>[deleted]
Please. There was little in this message that was on-topic for the
cygwin mailing list. Please use the cygwin-talk mailing list if you
really want to pursue this further.
--
Problem reports: http://cygwin.com/problem
I found this message in my hosted Gmail (Google Apps) account’s Spam
folder. I wonder why Gmail thought it was spam? Because it contained
the URL of a(n) (Windows) executable file?
Dave Korn wrote:
G.W. Haywood wrote:
BTW, if you run "setup.exe --help", it will (depending on OS
version) ei
Hello again,
On Mon, 18 Jan 2010 we variously wrote:
> > That's not correct (*):
>
> Well strictly it is, since I said what would happen if you ran it, and not
> what would happen if you _didn't_ run it (for whatever reason that might
> happen to be)!
Damn. Aced. 15-love.
> [da...@ubique ~]$
On Mon, Jan 18, 2010 at 01:23:27PM +, Dave Korn wrote:
>G.W. Haywood wrote:
>> Yes, one could just *try it*, if he had a Windows machine on which to
>> try it.
>
>*koff* Prepare to be shocked, amazed, awed and astounded!
This thread was started because Barry Buchbinder noticed a discrepancy
b
On Mon, Jan 18, 2010 at 12:18:13PM +, G.W. Haywood wrote:
>I wasn't joking about the professional help. There's clearly some
>deep seated need there to dominate people. Unfortunately it won't
>work with everyone.
Please question my sanity in the cygwin-talk mailing list. While it
may be ent
G.W. Haywood wrote:
>> BTW, if you run "setup.exe --help", it will (depending on OS
>> version) either display the usage instructions to the screen, or
>> dump them to a setup.log file in the directory where you run it.
>
> That's not correct (*):
>
> laptop:~$ >>> ./setup.exe
> -bash: ./setup.e
Hello again,
On Mon, 18 Jan 2010 several of us wrote:
> > 73,
> > Ged.
>
> Now I'm confused. Is that your high-score, your shoe size, or your age?
It's a relic from the days of morse code; just over my weight, and
half my IQ; and uncomfortably close to my age.
> BTW, if you run "setup.exe --he
On Sun, Jan 17, 2010 at 10:32:43AM +, Dave Korn wrote:
>Dave Korn wrote:
>>G.W. Haywood wrote:
>>>On Sun, 17 Jan 2010 Christopher Faylor wrote:
On Sat, Jan 16, 2010 at 09:17:24AM +, G.W. Haywood wrote:
>Which is correct?
If only there was some way to tell...
>>>I think you sho
On Sun, Jan 17, 2010 at 08:15:36AM +, G.W. Haywood wrote:
>On Sun, 17 Jan 2010 Christopher Faylor wrote:
>>On Sat, Jan 16, 2010 at 09:17:24AM +, G.W. Haywood wrote:
>>>Which is correct?
>>
>>If only there was some way to tell...
>
>I think you should seek professional help.
Wow! Zing!
c
Dave Korn wrote:
> G.W. Haywood wrote:
>> Hi there,
>>
>> On Sun, 17 Jan 2010 Christopher Faylor wrote:
>>
>>> On Sat, Jan 16, 2010 at 09:17:24AM +, G.W. Haywood wrote:
>>>
Which is correct?
>>> If only there was some way to tell...
>> I think you should seek professional help.
>
> Nurs
G.W. Haywood wrote:
> Hi there,
>
> On Sun, 17 Jan 2010 Christopher Faylor wrote:
>
>> On Sat, Jan 16, 2010 at 09:17:24AM +, G.W. Haywood wrote:
>>
>>> Which is correct?
>> If only there was some way to tell...
>
> I think you should seek professional help.
Nurse! The screens!
> --
>
>
Hi there,
On Sun, 17 Jan 2010 Christopher Faylor wrote:
> On Sat, Jan 16, 2010 at 09:17:24AM +, G.W. Haywood wrote:
>
> > Which is correct?
>
> If only there was some way to tell...
I think you should seek professional help.
--
73,
Ged.
--
Problem reports: http://cygwin.com/problems
On Sat, Jan 16, 2010 at 09:17:24AM +, G.W. Haywood wrote:
>Hi there,
>
>http://cygwin.com/cygwin-ug-net/setup-net.html#internet-setup
>
>says
>
>"Unfortunately setup.exe does not yet support unattended installs."
>
>but
>
>http://cygwin.com/faq/faq-nochunks.html#faq.setup.cli
>
>seems to imply
Hi there,
http://cygwin.com/cygwin-ug-net/setup-net.html#internet-setup
says
"Unfortunately setup.exe does not yet support unattended installs."
but
http://cygwin.com/faq/faq-nochunks.html#faq.setup.cli
seems to imply that it does, via the '-q' switch.
Which is correct?
--
73,
Ged.
--
Pro
On Jan 15 13:47, Christopher Faylor wrote:
> On Fri, Jan 15, 2010 at 12:32:12PM -0500, Buchbinder, Barry (NIH/NIAID) [E]
> wrote:
> >The command line arguments listed in the FAQ
> >http://cygwin.com/faq/faq-nochunks.html#faq.setup.cli
> >are incomplete. The following
On Fri, Jan 15, 2010 at 12:32:12PM -0500, Buchbinder, Barry (NIH/NIAID) [E]
wrote:
>The command line arguments listed in the FAQ
>http://cygwin.com/faq/faq-nochunks.html#faq.setup.cli
>are incomplete. The following are missing.
>
> -O --only-site Ignore a
The command line arguments listed in the FAQ
http://cygwin.com/faq/faq-nochunks.html#faq.setup.cli
are incomplete. The following are missing.
-O --only-site Ignore all sites except for -s
-P --packages Specify packages to install
-C
alid argument
While if I give it an argument 32729 characters long
$ ls `gawk 'BEGIN {for (N = 1; N < 32729; N++) {printf "X"}; print
"";exit}'`
[snip]: File or path name too long
So something changes when the command line arguments get too long.
- Ba
Hi Barry,
Buchbinder, Barry (NIH/NIAID) wrote on Thursday, October 23, 2003 12:43 AM:
> While doing some other work, I've come to the impression that
> this is not a fileutils problem. In a directory with ~1700
> htm files whose names take 37k,
> $ ls *
> bash: /bin/ls.exe: Invalid argument
>
While doing some other work, I've come to the impression that this is not a
fileutils problem. In a directory with ~1700 htm files whose names take
37k,
$ zip archive_name *.htm
bash: /bin/zip: Invalid argument
but
$ echo * | tr ' ' '\n' | zip t.zip -@
worked fine. I did it again using sh.
$
83 matches
Mail list logo
