X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=axrf4Ut
	pHbQXr5xjrpkbCcE3s6fKRGbZEJUKwTrsKdSjs/dLuwyvReYh1fQDBVvPDgPjVPm
	s7T8iA9ZhJ1LLP5sr5BcF0AoNh3GVYUW5Ar4jliercXC12D+ErdTNIGE3DbkFq7X
	KGfethpI0dtFXebF81iHKAP46mOEQQy8FCN0=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; s=default; bh=7OrLHEb44H2bd
	MBHADn88Qo1AQc=; b=pt8IJWnLaGupXfeterM1BI4XOnCzOHfijqkblH6WSiG+r
	wndnYRd4uShnh3WczXihwXyqcRaOzn2ZR9xwHoDkzQB0tXyOuVhAH1yEoNfHkTLu
	LJ6s4T/v0fLJ2zMiCBFZSAg0dVn4GwDyBDpp1REusvGc4sTkZJtu6Kj7dQw6zw=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-0.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Bash, path2, path1, parenthesis
X-HELO:	mail-it0-f43.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=LbYopak+oZbBUmJQXo/uSQ/Qux4jv0xB+TOvju4IMXs=; b=c0D6LHJEEpx+D2PSXkQ01wuW8OVf6yN4VsZ1jm5BvXuGfp7NXRFbH8eYbKgOykN2rh HW1jqL5fiHtc704ymQEMYCUOhamM6hl4MaJyl86lMCqpkP7impAOwHXm7nWV5nMElhTv MSA4iJrtSimGon0JptVVM5uMFbTj9uLGQ74VGfw/N9OsKD8l2HpEzLz03kJ16B4n0lCC kmsXf/t7IJXEu0YttS5kfPGPGba95tlgALIslBVBuNJnrU+ppwUBUpQ1ogsDkU8Sq85s S0Jox1iUYlNqPRaP270iV5xYSmUWTd6N2H4Y7C2tiLIKyKaNIoyytRrvfAeNsFH63Rtx EBgA==
X-Gm-Message-State:	AE9vXwOWoYBfaRS2DKFvGEprdpZQ/74+/MfnkLi/aH9VpnrssiQaGC0yDdUURQqV7QcXdsi9FgxXzEPUOV/Izw==
X-Received:	by 10.157.17.88 with SMTP id p24mr4846277otp.65.1473449847205; Fri, 09 Sep 2016 12:37:27 -0700 (PDT)
MIME-Version:	1.0
In-Reply-To:	<eb1c8bc2-6f49-47ae-73ee-7acefd7fefc8@redhat.com>
References:	<330568691 DOT 2384551 DOT 1473201409220 DOT ref AT mail DOT yahoo DOT com> <330568691 DOT 2384551 DOT 1473201409220 AT mail DOT yahoo DOT com> <c0b897be-d3cf-f3b9-cf5b-0024a1d395e5 AT redhat DOT com> <1709131555 DOT 354781 DOT 1473264514358 AT mail DOT yahoo DOT com> <15510127987 DOT 20160907202742 AT yandex DOT ru> <eb1c8bc2-6f49-47ae-73ee-7acefd7fefc8 AT redhat DOT com>
From:	Gene Pavlovsky <gene DOT pavlovsky AT gmail DOT com>
Date:	Fri, 9 Sep 2016 22:37:26 +0300
Message-ID:	<CAPTiy3MNiVnnRF9MNym-VCMEMCt6FRTrKKAWx2AdS3_3k6VNXg@mail.gmail.com>
Subject:	Re: Bash shell script issue
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes

On 7 September 2016 at 21:27, Eric Blake <eblake AT redhat DOT com> wrote:
>>> project_root=$PWD
>>
>> Still bad.
>
> No, that one's good.  Quotes are only REQUIRED when you want to ensure
> that there is no word splitting or globbing going on, and assignment
> context has neither of those.  However, although the quotes are optional
> in that context, using them out of habit makes it easier to remember to
> use quotes in the contexts where it does matter.

I was going to say that. Consider the following example:

# path1='/mnt/c/Program Files (x86)'
22:12:49 ~
# path2=$path1
22:12:54 ~
# path3=$path2/tools
22:13:00 ~
# echo $path1
/mnt/c/Program Files (x86)
22:13:05 ~
# echo $path2
/mnt/c/Program Files (x86)
22:13:06 ~
# echo $path3
/mnt/c/Program Files (x86)/tools

Assignment requires no extra quoting.
However if you try
# test -d $path2 && echo $path2 is a directory
bash: test: too many arguments

Because $path2 becomes split by space into words, while `test -d`
expects only one argument.
# test -d "$path2" && echo $path2 is a directory
/mnt/c/Program Files (x86) is a directory

This is really bash basics, and you should read Bash Beginner's Guide:
http://tldp.org/LDP/Bash-Beginners-Guide/html/

And just remember that UNIX tools such as bash, sed, awk etc. expect
scripts to use UNIX-style line endings (one LF character ends the
line), as opposed to a pair of CR and LF characters used in Windows.
Whenever you encounter problems or error messages that don't seem to
make any sense, check the file line endings. You can use the `file`
command to check the file's line endings. An example bash session:

22:22:49 ~
# cat >test.sh <<EOF
> #!/bin/sh
>
> echo line ending test script
> EOF
22:23:29 ~
# chmod 755 test.sh
22:23:14 ~
# u2d test.sh
unix2dos: converting file test.sh to DOS format...
22:23:24 ~
# file test.sh
test.sh: POSIX shell script, ASCII text executable, with CRLF line terminators
22:23:36 ~
# ./test.sh
./test.sh: line 2: $'\r': command not found
line ending test script
22:23:37 ~
# d2u test.sh
dos2unix: converting file test.sh to Unix format...
22:23:41 ~
# file test.sh
test.sh: POSIX shell script, ASCII text executable
22:23:43 ~
# ./test.sh
line ending test script

Here I've created a test shell script, and deliberately converted it
to DOS (Windows) line endings. The `file` command explicitly tells you
it has CRLF line terminators.
Next try to run the script and it will not work, because the
supposedly empty line is considered as a single `\r` (CR) character,
which is not a valid command.
After converting the file back to UNIX line endings, the `file`
command doesn't mention anything about line endings, because they are
the standard/default/normal UNIX-style ones (`\n` = LF). The script
runs.

Personally I use Notepad2-mod to edit shell scripts, the `File > Line
Endings` shows you the current line endings, allows to convert between
different line ending styles, and allows to set UNIX style as default.
Link if you're interested: http://xhmikosr.io/notepad2-mod/

> No, that one's okay.  In fact, if you are going for minimalism, you
> could use:
>
> x=$project_root/tools
>
> as the ${} form is only REQUIRED when you are using operators inside {}
> or when the next character after } is ambiguous with a continuation of
> the name of the variable in after the $.

Minimalism is good, but when writing anything more or less
complicated, consistent style and coding conventions become more
important. Quoting a variable in one context, but not the other, using
${var1}_${var2} here, but plain $var1$var2 etc. - it will work, but it
might not be best idea to code/script like this. Same as sometimes
it's better to put an extra set of otherwise unnecessary parenthesis
in a math expression, just to group terms and make the expression more
readable and operator precedence more obvious.
Bash has a lot of different syntax, and beginners would bump into less
problems if they overquote rather than underquote...
This is personal opinion based on my software development experience,
mostly working with high-level languages, involving complicated
architectural frameworks: sometimes you write more than strictly
necessary, to prevent problems in the future, make code more readable,
maintainable etc.

Regards,
--Gene

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

- Raw text -