"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Stefan Sperling <stsp@stsp.name>
Subject:
Re: dial fix for git-shell
To:
Omar Polo <op@omarpolo.com>
Cc:
gameoftrees@openbsd.org
Date:
Wed, 8 Mar 2023 19:58:48 +0100

Download raw body.

Thread
On Wed, Mar 08, 2023 at 06:15:20PM +0100, Omar Polo wrote:
> let's say you have a repo called "rock'n'roll.git", once encoded the
> string becomes 'rock'\''n'\''roll.git'; expanded for readability is
> 'rock' \' 'n' \' 'roll'
> 
> this differs with how C and most programming language do escaping.
> '\'' in C is the literal character single quote, in sh it's a
> backslash followed by an un-terminated string.

Ah, fair enough then. Good to know.

> > My reading of both bash(1) and ksh(1) man pages suggests that no character
> > needs to be escaped (not even newlines) until another single quote appears.
> 
> That's my reading too.  csh(1) seems to have a quirk: "Within pairs of
> ‘'’ or ‘"’ characters, a newline preceded by a '\' gives a true
> newline character."  Don't think we need to cope though.
> 
> > So maybe we could just scan the path for a single-quote character and raise
> > an error if it contains one? And that's it?
> 
> Well, we could, but it'd break fetching from repos with single quotes
> in their name.  Now, I don't feel strongly about these, I don't even
> use spaces in paths let alone fancy chars, but the implementation is
> simple and doesn't add complexity to dial.c...

Given your explanation above I am fine with your diff.

It would be nice to have a test case for a rock'n'roll repo and perhaps
even one that uses git-shell? Perhaps git-shell would best be done in
the gotd test suite since we there is more manual setup required for those
already. We could require yet another user account which uses git-shell
as its login shell and run some tests against it. I will look into this.