RE: sh -c and newline
Ah I never knew about ^. Thanks a lot for that tip. I'll try it out tomorrow. Yeah I work in the backup/data protection division here, From: cygwin-ow...@cygwin.com [cygwin-ow...@cygwin.com] on behalf of Brian Inglis [brian.ing...@systematicsw.ab.ca] Sent: Monday, December 05, 2016 6:30 PM To: cygwin@cygwin.com Subject: Re: sh -c and newline On 2016-12-05 14:11, Gluszczak, Glenn wrote: > On 2016-12-05 15:04, Brian Inglis wrote: >> On 2016-12-05 12:38, Gluszczak, Glenn wrote: >>> I can't seem to get sh -c to recognize newline. Tcsh -c works. >>> I'm using echo as an example but I'm actually trying to build a >>> here-document. >>> %%%sh -c "echo \nhello" >>> nhello >>> %%%sh -c "echo \\nhello" >>> nhello >>> %%%sh -c "echo \\\nhello" >>> \nhello >>> %%%tcsh -c "echo \nhello" >>> nhello >>> %%%tcsh -c "echo \\nhello" >>> \nhello >>> %%%tcsh -c "echo \\\nhello" >>> hello >> Your login shell is scanning and interpreting escapes in the input, then the >> subshell you are running, so you need to quote \n to let echo see it. >> Builtin echo does not recognize escapes without -e. >> You can use echo -e, or $ prefix a single quoted string to have the shell >> interpret the escape sequence. >> $ sh -c "echo -e '\nhello'" >> >> hello >> $ sh -c "echo $'\n'hello" >> >> hello >> $ sh -c "echo $'\nhello'" >> >> hello > Thank you for the answer Brian. I was trying to show a problem with a > HERE document and used echo but it is not the exact same issue. > I forgot about the order of substitution; my original issue is > similar. > In CMD, you can't have multiple lines for sh -c but in shell you can > sh -c "cat -< hello > EOF" > Turns out the newlines are being sent, but CMD thinks a command is > only on one line. Perhaps there is a way to specify multiple lines in > a cmd prompt. Use can use & in cmd like ; in bash and && works the same in both; with conditional and loop constructs in cmd, you can use: if|for ... (command1... command2... ) across multiple lines, and you can use ^ in cmd like \ in bash for both line continuation and escaping. Learned this stuff porting some shell scripts to cmd for use by folks on backup or home desktops during Disaster Recovery and migration backup tests, so they could download and prep data locally, in case any of the Unix or file servers, or network, to do this automatically and transparently were inaccessible. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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 -- 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
Re: sh -c and newline
On 2016-12-05 14:11, Gluszczak, Glenn wrote: > On 2016-12-05 15:04, Brian Inglis wrote: >> On 2016-12-05 12:38, Gluszczak, Glenn wrote: >>> I can't seem to get sh -c to recognize newline. Tcsh -c works. >>> I'm using echo as an example but I'm actually trying to build a >>> here-document. >>> %%%sh -c "echo \nhello" >>> nhello >>> %%%sh -c "echo \\nhello" >>> nhello >>> %%%sh -c "echo \\\nhello" >>> \nhello >>> %%%tcsh -c "echo \nhello" >>> nhello >>> %%%tcsh -c "echo \\nhello" >>> \nhello >>> %%%tcsh -c "echo \\\nhello" >>> hello >> Your login shell is scanning and interpreting escapes in the input, then the >> subshell you are running, so you need to quote \n to let echo see it. >> Builtin echo does not recognize escapes without -e. >> You can use echo -e, or $ prefix a single quoted string to have the shell >> interpret the escape sequence. >> $ sh -c "echo -e '\nhello'" >> >> hello >> $ sh -c "echo $'\n'hello" >> >> hello >> $ sh -c "echo $'\nhello'" >> >> hello > Thank you for the answer Brian. I was trying to show a problem with a > HERE document and used echo but it is not the exact same issue. > I forgot about the order of substitution; my original issue is > similar. > In CMD, you can't have multiple lines for sh -c but in shell you can > sh -c "cat -< hello > EOF" > Turns out the newlines are being sent, but CMD thinks a command is > only on one line. Perhaps there is a way to specify multiple lines in > a cmd prompt. Use can use & in cmd like ; in bash and && works the same in both; with conditional and loop constructs in cmd, you can use: if|for ... (command1... command2... ) across multiple lines, and you can use ^ in cmd like \ in bash for both line continuation and escaping. Learned this stuff porting some shell scripts to cmd for use by folks on backup or home desktops during Disaster Recovery and migration backup tests, so they could download and prep data locally, in case any of the Unix or file servers, or network, to do this automatically and transparently were inaccessible. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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
Re: sh -c and newline
On 2016-12-05 12:38, Gluszczak, Glenn wrote: > I can't seem to get sh -c to recognize newline. Tcsh -c works. > I'm using echo as an example but I'm actually trying to build a > here-document. > %%%sh -c "echo \nhello" > nhello > %%%sh -c "echo \\nhello" > nhello > %%%sh -c "echo \\\nhello" > \nhello > %%%tcsh -c "echo \nhello" > nhello > %%%tcsh -c "echo \\nhello" > \nhello > %%%tcsh -c "echo \\\nhello" > hello Your login shell is scanning and interpreting escapes in the input, then the subshell you are running, so you need to quote \n to let echo see it. Builtin echo does not recognize escapes without -e. You can use echo -e, or $ prefix a single quoted string to have the shell interpret the escape sequence. $ sh -c "echo -e '\nhello'" hello $ sh -c "echo $'\n'hello" hello $ sh -c "echo $'\nhello'" hello -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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
sh -c and newline
I can't seem to get sh -c to recognize newline. Tcsh -c works. I'm using echo as an example but I'm actually trying to build a here-document. %%%sh -c "echo \nhello" nhello %%%sh -c "echo \\nhello" nhello %%%sh -c "echo \\\nhello" \nhello %%%tcsh -c "echo \nhello" nhello %%%tcsh -c "echo \\nhello" \nhello %%%tcsh -c "echo \\\nhello" hello -- 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
Re: Installer names not meaningful enough
On 2016-12-05 10:36, Stephen Paul Carrier wrote: > On Thu, Dec 01, 2016 at 11:37:41AM -0500, Ian Lambert wrote: >> On December 1, 2016 8:54:57 AM EST, cyg Simplewrote: >>> >>> >>> On 12/1/2016 8:25 AM, Vlado wrote: On 1.12.2016 13:51, Eliot Moss wrote: > I think that including the version of the setup program could be >>> helpful > - I tend > to add it (renaming the file by hand). However, clearly we've lived > with things this > way for a long time ... >>> >>> More than a score years. >>> I disagree. I have a script to update Cygwin. This script checks for new version >>> of setup, downloads, verifies signature, etc. Things would become much >>> more complicated with variable setup file name. Finally: Why should I care about the exact version number of setup? Script makes backups of the old setup files like setup.exe.0001, >>> 0002, ..., just for a cause, but never in the past I did have to looking >>> for the setup with exact version number. >>> >>> The only reason would be if you had an older version of the .ini file. >>> When the data prerequisites of the .ini file change there is a new >>> version of setup to handle that. > > Right, and the way to learn if this is the case is to run setup. I learn > that a new version is available by running the old version. > > Running setup is also the way to find out what is the version. > > I don't mind renaming the file myself, but would really appreciate any > way to know from the cygwin.com front page exactly which version of the > setup-*.exe is on offer. (The current version of Cygwin DLL is useful, > but not the same thing.) You can get the Setup version by installing upx and running: cp -fp $DIR/setup-x86*.exe /tmp/setup && \ upx -dqqq /tmp/setup&& \ egrep -ao '%%%\ssetup-version\s[.0-9]+' /tmp/setup | \ sed 's/%%%\ssetup-version\s//' && \ rm -f /tmp/setup -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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
Re: Installer names not meaningful enough
On 12/5/2016 1:25 PM, Andrey Repin wrote: Greetings, Stephen Paul Carrier! I don't mind renaming the file myself, but would really appreciate any way to know from the cygwin.com front page exactly which version of the setup-*.exe is on offer. (The current version of Cygwin DLL is useful, but not the same thing.) That may (will!) confuse people not familiar with insides of Cygwin environment. Possibly, but it doesn't strike me as overly difficult to explain that these are different version sequences. We also might be able to make the two numbering schemes look sufficiently different that they would be harder to confuse ... Regards - Eliot Moss -- 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
Re: Installer names not meaningful enough
Greetings, Stephen Paul Carrier! > I don't mind renaming the file myself, but would really appreciate any > way to know from the cygwin.com front page exactly which version of the > setup-*.exe is on offer. (The current version of Cygwin DLL is useful, > but not the same thing.) That may (will!) confuse people not familiar with insides of Cygwin environment. -- With best regards, Andrey Repin Monday, December 5, 2016 21:25:04 Sorry for my terrible english... -- 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
Re: Installer names not meaningful enough
On Thu, Dec 01, 2016 at 11:37:41AM -0500, Ian Lambert wrote: > On December 1, 2016 8:54:57 AM EST, cyg Simplewrote: > > > > > >On 12/1/2016 8:25 AM, Vlado wrote: > >> On 1.12.2016 13:51, Eliot Moss wrote: > >>> I think that including the version of the setup program could be > >helpful > >>> - I tend > >>> to add it (renaming the file by hand). However, clearly we've lived > >>> with things this > >>> way for a long time ... > > > >More than a score years. > > > >> > >> I disagree. > >> I have a script to update Cygwin. This script checks for new version > >of > >> setup, downloads, verifies signature, etc. Things would become much > >more > >> complicated with variable setup file name. > >> Finally: Why should I care about the exact version number of setup? > >> Script makes backups of the old setup files like setup.exe.0001, > >0002, > >> ..., just for a cause, but never in the past I did have to looking > >for > >> the setup with exact version number. > >> > > > >The only reason would be if you had an older version of the .ini file. > >When the data prerequisites of the .ini file change there is a new > >version of setup to handle that. Right, and the way to learn if this is the case is to run setup. I learn that a new version is available by running the old version. Running setup is also the way to find out what is the version. I don't mind renaming the file myself, but would really appreciate any way to know from the cygwin.com front page exactly which version of the setup-*.exe is on offer. (The current version of Cygwin DLL is useful, but not the same thing.) Stephen Carrier -- 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