public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@linux.intel.com>
To: Otavio Salvador <otavio@ossystems.com.br>
Cc: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>,
	Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>,
	Darren Hart
	<public-dvhart-VuQAYsv1563Yd54FQh9/CA@plane.gmane.org>
Subject: Re: [PATCH 7/8] oe-git-proxy.sh: Add a new comprehensive git proxy script
Date: Tue, 05 Feb 2013 10:50:59 -0800	[thread overview]
Message-ID: <51115493.1040504@linux.intel.com> (raw)
In-Reply-To: <CAP9ODKr1qz6=k7xC84h0Try0HsydDhNyERPzuW-FhuaLRbYajQ@mail.gmail.com>



On 02/05/2013 10:40 AM, Otavio Salvador wrote:
> On Tue, Feb 5, 2013 at 3:44 PM, Darren Hart <dvhart@linux.intel.com> wrote:
>>
>>
>> On 02/05/2013 08:36 AM, Enrico Scholz wrote:
>>> Darren Hart <dvhart@linux.intel.com> writes:
>>>
>>>>>> +  $NC -X connect $*
>>>>>
>>>>> why '$*' but not '"$@*"'?
>>>>>
>>>> I'm not familiar with $@*
>>>
>>> sorry... I meant "$@"
>>>
>>>
>>>> As for $* versus $@, the issue is how the arguments are presented. $*
>>>> as a single word, $@ each argument is quoted separately. I believe I
>>>> ran into issues with $@. I haven't had any trouble with $*.
>>>
>>> $* is causing trouble all the time because it does not retain whitespaces
>>> or empty parameters.  There are only very few cases, where $* makes sense.
>>>
>>>
>>>> Is there a particular use case where you can see this failing as is?
>>>
>>> "$@" is just the right thing to do in this situation.  E.g. when your
>>> script is called as
>>>
>>> | oe-git-proxy.sh "${HOST}" "${PORT}"
>>>
>>> and HOST is undefined due to some reason, you will try to connect to
>>> "${PORT}" with $*.  The "$@" will cause nc to complain about the broken
>>> HOST parameter.
>>>
>>>
>>> Btw...
>>>
>>> | exec $NC $METHOD "$@"
>>>
>>> would be the school book implementation for the thing you want to do...
>>>
>>>
>>>
>>> Enrico
>>
>> That all makes sense. When I read up the difference again in the bash
>> documentation I was surprised I had used $*, but thought I had done that
>> dance already. I'll update with "$@" and do some tests.
>>
>> Thank you for the review and catching that.
> 
> Please give it a try in dash as well.

$@ also works with dash. I have been testing in bash and dash throughout
development as well.


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel



  reply	other threads:[~2013-02-05 19:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-05 10:31 [PATCH 0/8] Git fetcher and proxy handling updates Darren Hart
2013-02-05 10:31 ` [PATCH 1/8] bitbake: fetch2: Print the complete SRCREV variable name when INVALID Darren Hart
2013-02-05 10:31 ` [PATCH 2/8] bitbake: fetch2: Export upper and lower case environment variables Darren Hart
2013-02-05 10:31 ` [PATCH 3/8] bitbake: fetch2: Remove broken git variables from the environment Darren Hart
2013-02-05 10:31 ` [PATCH 4/8] oe-buildenv-internal: Remove GIT variables from BB_ENV_EXTRAWHITE Darren Hart
2013-02-05 10:31 ` [PATCH 5/8] oe-buildenv-internal: Add upper and lower case proxy vars to BB_ENV_EXTRAWHITE Darren Hart
2013-02-05 10:31 ` [PATCH 6/8] base.bbclass: Remove generate_git_config() Darren Hart
2013-02-05 10:31 ` [PATCH 7/8] oe-git-proxy.sh: Add a new comprehensive git proxy script Darren Hart
2013-02-05 11:16   ` Enrico Scholz
2013-02-05 16:20     ` Darren Hart
2013-02-05 16:36       ` Enrico Scholz
2013-02-05 17:44         ` Darren Hart
2013-02-05 18:40           ` Otavio Salvador
2013-02-05 18:50             ` Darren Hart [this message]
2013-02-05 19:08             ` Enrico Scholz
2013-02-05 19:18               ` Darren Hart
2013-02-05 19:29                 ` Otavio Salvador
2013-02-05 22:10                 ` Richard Purdie
2013-02-05 10:31 ` [PATCH 8/8] git proxy: Document usage of oe-git-proxy.sh and remove alternatives Darren Hart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51115493.1040504@linux.intel.com \
    --to=dvhart@linux.intel.com \
    --cc=enrico.scholz@sigma-chemnitz.de \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=otavio@ossystems.com.br \
    --cc=public-dvhart-VuQAYsv1563Yd54FQh9/CA@plane.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox