Re: [PATCH 1/3] rev-parse: add --sq-quote to shell quote arguments

Christian Couder [off-list ref] writes:

Hmph, I wonder how this interacts with the existing --sq option to the
same command in the mental model of end users.

+Example
+~~~~~~~
+
+------------
+$ git rev-parse --sq-quote "'''" '"""' "arg with space"
+ ''\'''\'''\''' '"""' 'arg with space'
+------------

Yuck --- does asciidoc formats this correctly?

    ... goes and tries ...

Not very readable.  A better example might be to demonstrate something
like this:

	$ cat >your-git-script.sh <<\EOF
	#!/bin/sh
	# quote user-supplied arguments
	args=$(git rev-parse --sq-quote "$@")
        # and use it inside a handcrafted command line
        command="git frotz -n24 $args"
        eval "$command"
	EOF

	$ sh your-git-script.sh "a b'c"

i.e, put stress on how to use it, not on how it works internally.

Junio C Hamano schrieb:

Not very readable.  A better example might be to demonstrate something
like this:

	$ cat >your-git-script.sh <<\EOF
	#!/bin/sh
	# quote user-supplied arguments
	args=$(git rev-parse --sq-quote "$@")
        # and use it inside a handcrafted command line
        command="git frotz -n24 $args"
        eval "$command"
	EOF

	$ sh your-git-script.sh "a b'c"

i.e, put stress on how to use it, not on how it works internally.

Hmm, that makes me wonder why we special-case shell-quoting and implement
it in an executable. Why don't we have perl-quoting, C-quoting,
PHP-quoting, $language-of-your-choice quoting, etc, too?

I think we should simply move sq() from git-am to git-sh-setup and use
that in git-bisect.

-- Hannes

Le vendredi 24 avril 2009, Junio C Hamano a écrit :

Christian Couder [off-list ref] writes:

quoted

@@ -30,6 +30,9 @@ OPTIONS
 	Only meaningful in `--parseopt` mode. Tells the option parser to echo
 	out the first `--` met instead of skipping it.

+--sq-quote::
+	Use 'git-rev-parse' in shell quoting mode (see SQ-QUOTE section

below). +

Hmph, I wonder how this interacts with the existing --sq option to the
same command in the mental model of end users.

I just sent a new version where difference between --sq and --sq-quote are 
discussed.

quoted

+Example
+~~~~~~~
+
+------------
+$ git rev-parse --sq-quote "'''" '"""' "arg with space"
+ ''\'''\'''\''' '"""' 'arg with space'
+------------

Yuck --- does asciidoc formats this correctly?

    ... goes and tries ...

Not very readable.  A better example might be to demonstrate something
like this:

	$ cat >your-git-script.sh <<\EOF
	#!/bin/sh
	# quote user-supplied arguments
	args=$(git rev-parse --sq-quote "$@")
        # and use it inside a handcrafted command line
        command="git frotz -n24 $args"
        eval "$command"
	EOF

	$ sh your-git-script.sh "a b'c"

i.e, put stress on how to use it, not on how it works internally.

I agree your example is better. I used it in the v2 I just sent.

Thanks,
Christian.

Le vendredi 24 avril 2009, Johannes Sixt a écrit :

Junio C Hamano schrieb:

quoted

Not very readable.  A better example might be to demonstrate something
like this:

	$ cat >your-git-script.sh <<\EOF
	#!/bin/sh
	# quote user-supplied arguments
	args=$(git rev-parse --sq-quote "$@")
        # and use it inside a handcrafted command line
        command="git frotz -n24 $args"
        eval "$command"
	EOF

	$ sh your-git-script.sh "a b'c"

i.e, put stress on how to use it, not on how it works internally.

Hmm, that makes me wonder why we special-case shell-quoting and implement
it in an executable. Why don't we have perl-quoting, C-quoting,
PHP-quoting, $language-of-your-choice quoting, etc, too?

Because there are a lot of shell scripts in the Git source code and it's an 
important problem for shell scripts to properly handle arguments.

I think we should simply move sq() from git-am to git-sh-setup and use
that in git-bisect.

We already have an implementation of shell quoting in C, why not use it 
everywhere instead of having 2 implementations?

And what happens if someone want to port to C a shell script that uses sq()?
The implementation used will have to be the one in C, so why not use it 
right now?

Regards,
Christian.