RE: sh -c and newline

2016-12-05 Thread Gluszczak, Glenn
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

2016-12-05 Thread Brian Inglis
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

2016-12-05 Thread Brian Inglis
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

2016-12-05 Thread Gluszczak, Glenn

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

2016-12-05 Thread Brian Inglis
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 Simple  wrote:
>>>
>>>
>>> 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

2016-12-05 Thread Eliot Moss

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

2016-12-05 Thread Andrey Repin
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

2016-12-05 Thread Stephen Paul Carrier
On Thu, Dec 01, 2016 at 11:37:41AM -0500, Ian Lambert wrote:
> On December 1, 2016 8:54:57 AM EST, cyg Simple  wrote:
> >
> >
> >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