From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55695 invoked by alias); 9 Sep 2016 19:37:40 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 55685 invoked by uid 89); 9 Sep 2016 19:37:40 -0000 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 Received: from mail-it0-f43.google.com (HELO mail-it0-f43.google.com) (209.85.214.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Sep 2016 19:37:30 +0000 Received: by mail-it0-f43.google.com with SMTP id w189so3563151ith.0 for ; Fri, 09 Sep 2016 12:37:29 -0700 (PDT) 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 Received: by 10.79.87.195 with HTTP; Fri, 9 Sep 2016 12:37:26 -0700 (PDT) In-Reply-To: References: <330568691.2384551.1473201409220.ref@mail.yahoo.com> <330568691.2384551.1473201409220@mail.yahoo.com> <1709131555.354781.1473264514358@mail.yahoo.com> <15510127987.20160907202742@yandex.ru> From: Gene Pavlovsky Date: Fri, 09 Sep 2016 19:37:00 -0000 Message-ID: Subject: Re: Bash shell script issue To: cygwin@cygwin.com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00156.txt.bz2 On 7 September 2016 at 21:27, Eric Blake 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 < #!/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