Re: 3.5.x regression: misquoting command line arguments from native processes

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

Re: cygrunsrv: trailing command line arguments not allowed

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

Re: 3.5.x regression: misquoting command line arguments from native processes

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

Re: 3.5.x regression: misquoting command line arguments from native processes

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

Re: 3.5.x regression: misquoting command line arguments from native processes

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 >

3.5.x regression: misquoting command line arguments from native processes

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

Re: surrounding double quotes not removed from native command line arguments when they contain unicode and locale is default

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

surrounding double quotes not removed from native command line arguments when they contain unicode and locale is default

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

Re: gnuplot dollar sign and command line arguments

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 enab

gnuplot dollar sign and command line arguments

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 expressions to command

setup.exe ignores unrecognized command-line arguments silently

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

Re: Cygwin Setup Command-line Arguments - Paths with a Space Incorrectly Parsed

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:\=/%

Re: Cygwin Setup Command-line Arguments - Paths with a Space Incorrectly Parsed

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

Re: Cygwin Setup Command-line Arguments - Paths with a Space Incorrectly Parsed

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

Re: Cygwin Setup Command-line Arguments - Paths with a Space Incorrectly Parsed

> 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:

Re: Cygwin Setup Command-line Arguments - Paths with a Space Incorrectly Parsed

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

Cygwin Setup Command-line Arguments - Paths with a Space Incorrectly Parsed

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 then save batch

RE: Formatting command line arguments when starting a Cygwin process from a native process

eter 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 backslashes (more evidence, i

RE: Formatting command line arguments when starting a Cygwin process from a native process

> This should help: > > https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/e > > veryone-quotes-command-line-arguments-the-wrong-way/ > > This provides documentation for how Microsoft implementations do it, not how > Cygwin does it. The Cygwin DLL is resp

RE: Formatting command line arguments when starting a Cygwin process from a native process

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

Re: Formatting command line arguments when starting a Cygwin process from a native process

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 before

RE: Formatting command line arguments when starting a Cygwin process from a native process

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 relates

RE: Formatting command line arguments when starting a Cygwin process from a native process

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 >

RE: Formatting command line arguments when starting a Cygwin process from a native process

gt; 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.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/e > veryone-quotes-command-line-arguments-t

RE: Formatting command line arguments when starting a Cygwin process from a native process

nts of argv, but I cannot > 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

Re: Formatting command line arguments when starting a Cygwin process from a native process

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-arguments-the-wrong

Re: Formatting command line arguments when starting a Cygwin process from a native process

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

RE: Formatting command line arguments when starting a Cygwin process from a native process

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, >

Re: Formatting command line arguments when starting a Cygwin process from a native process

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

Re: Formatting command line arguments when starting a Cygwin process from a native process

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

RE: Formatting command line arguments when starting a Cygwin process from a native process

[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

Re: Formatting command line arguments when starting a Cygwin process from a native process

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

Formatting command line arguments when starting a Cygwin process from a native process

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

Re: ps with command line arguments

20318 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 arguments, so the script can't

Re: ps with command line arguments

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. -- Problem reports: http

ps with command line arguments

?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/*/cmdline. However, some

Re: ps with command line arguments

./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 arguments, so the script can't list its instances. I was thinking about using

Re: ps with command line arguments

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

Re: ps with command line arguments

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

Re: Command line arguments

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 constantly type

Re: Command line arguments

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

Re: Command line arguments

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

Re: Command line arguments

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,

Re: Command line arguments

% ${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 but not /path/to/$1save/dir you'd need the {} % (i.e. /path/to/${1

Re: Command line arguments

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, ... % /path/to/$1.save/dir but not /path

Re: Command line arguments

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

Re: Command line arguments

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 found

Re: Command line arguments

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 /path/to/$1/dir. But if you

Re: Command line arguments

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 with $1, $2

Re: Command line arguments

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 {}'s

Command line arguments

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

Re: Command line arguments

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 all

Re: Command line arguments

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:

RE: Cygstart bug: doesn't keep command line arguments intact

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, don't

RE: Cygstart bug: doesn't keep command line arguments intact

. 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 Wiersba wrote August 03, 2012 3:18 PM Calling /c/program\ files/microsoft\ office/office12/winword.exe

Re: Cygstart bug: doesn't keep command line arguments intact

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 for how to

RE: Cygstart bug: doesn't keep command line arguments intact

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 the

Re: Cygstart bug: doesn't keep command line arguments intact

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

Cygstart bug: doesn't keep command line arguments intact

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

Re: [PATCH] Fix command line arguments for multiple monitors

On 18/04/2012 19:48, Jörg Mensmann wrote: I've now completed some additional tests, and it seems that the return value of EnumDisplayMonitors() really depends on the return value of its callback on my system. Here is the minimal test case: Thanks for the test case. Yes, you are quite correct.

Re: [PATCH] Fix command line arguments for multiple monitors

Hi, I've now completed some additional tests, and it seems that the return value of EnumDisplayMonitors() really depends on the return value of its callback on my system. Here is the minimal test case: static wBOOL CALLBACK getMonitorInfoTestTRUE(HMONITOR hMonitor, HDC hdc, LPRECT rect, LPARAM

Re: [PATCH] Fix command line arguments for multiple monitors

On 14/04/2012 16:28, Jörg Mensmann wrote: placing the X server on a specific monitor using something like -screen 0 @2 is broken since November. The attached patch restores the old behaviour. Thanks very much for investigating this issue and for the patch. I'll include this in the next X

Re: [PATCH] Fix command line arguments for multiple monitors

Jon TURNEY wrote: I'll include this in the next X server build. Thanks! I don't observe this behaviour on my test machine, EnumDisplayMonitor() returns TRUE, so I'd be interested to know what version of Windows you are using. The problem appeared on a Windows 7 machine with two monitors

[PATCH] Fix command line arguments for multiple monitors

Hi, placing the X server on a specific monitor using something like -screen 0 @2 is broken since November. The attached patch restores the old behaviour. ciao Jörg [PATCH] hw/xwin: Fix command line arguments for multiple monitors. Moving Xwin to a certain monitor using -screen 0 @2 would

GNU make builtin rules produce linker error due to command line arguments order

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

Re: GNU make builtin rules produce linker error due to command line arguments order

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

Re: GNU make builtin rules produce linker error due to command line arguments order

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

Re: GNU make builtin rules produce linker error due to command line arguments order

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

Re: missing setup command line arguments in the FAQ.

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)

Re: missing setup command line arguments in the FAQ.

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:

Re: missing setup command line arguments in the FAQ.

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 ~]$ wine

Re: missing setup command line arguments in the FAQ.

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 --help, it

Re: missing setup command line arguments in the FAQ.

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.exe: cannot

Re: missing setup command line arguments in the FAQ.

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

Re: missing setup command line arguments in the FAQ.

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 between

Re: missing setup command line arguments in the FAQ.

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.html

Re: missing setup command line arguments in the FAQ.

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! -- 73, Ged. Now

Re: missing setup command line arguments in the FAQ.

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. Nurse! The screens! BTW,

Re: missing setup command line arguments in the FAQ.

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! cgf --

Re: missing setup command line arguments in the FAQ.

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 should seek professional

Re: missing setup command line arguments in the FAQ.

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. --

Re: missing setup command line arguments in the FAQ.

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 that it does,

missing setup command line arguments in the FAQ.

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

Re: missing setup command line arguments in the FAQ.

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 all sites except for -s

Re: missing setup command line arguments in the FAQ.

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 are missing. -O --only-site

RE: Limit to length of command line arguments? (was Cygwin/bash: need environment variables 32K)

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. - Barry -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED

RE: Limit to length of command line arguments? (was Cygwin/bash: need environment variables 32K)

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, snip $ ls * bash: /bin/ls.exe: Invalid argument

Limit to length of command line arguments? (was Cygwin/bash: need environment variables 32K)

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.