From: Alex Riesen <alexander.riesen@cetitec.com>
To: "Jakub Narębski" <jnareb@gmail.com>
Cc: <git@vger.kernel.org>,
Pat Thoyts <patthoyts@users.sourceforge.net>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 1/2] Support for $FILENAMES in tool definitions
Date: Tue, 28 Jun 2016 10:54:21 +0200 [thread overview]
Message-ID: <20160628085421.GC3710@pflmari> (raw)
In-Reply-To: <57716227.1030104@gmail.com>
Jakub Narębski, Mon, Jun 27, 2016 19:28:07 +0200:
> On 2016-06-27, Alex Riesen wrote:
>
> > This adds a FILENAMES environment variable, which contains the repository
> > pathnames of all selected files the list.
> > The variable contains the names separated by spaces.
>
> Why not separate filenames with end-of-line character (LF)? It would still
> be broken for some filenames, but only for unportable ones. Filenames with
> internal space (common on MS Windows) would work then.
>
> http://www.dwheeler.com/essays/filenames-in-shell.html
>
Done. Thanks for the reference, BTW.
> If Tcl allows it, you could separate filenames in FILENAMES environment
> variable with NUL ("\0") character...
It allows using of NUL to join the file names. The problem is that the shell
does not know that the variable $FILENAMES doesn't end at the first NUL.
Looks like the script should do the expansion (and quoting!) on its own for
this. Or implement another syntax for custom tools, which will allow for, i.e.
passing the list of files on stdin. LF or NUL separated than.
> > Similar to the FILENAME it is broken yet, if the names contain spaces.
>
> Could you clarify? Did you meant that FILENAMES environment variable is
> similar to existing FILENAME variable, but broken for filenames which contain
> spaces, or did you mean that both FILENAME (how?) and FILENAMES are broken
> for filenames with spaces in them?
Passing a filename with spaces plainly $FILENAME into the command (i.e.
without quoting) produces multiple arguments instead of one.
The new $FILENAMES produces incorrect number of arguments for files with
spaces for the same reason.
> > Note that the file marked and diffed immediately after starting the GUI up,
> > is not actually selected. One must click on it once to really select it.
>
> I'm not that familiar with git-gui / gitk; what do you mean by this sentence?
The git-gui (its completely different from gitk) keeps two variables for
current files: a scalar variable for the file diff of which is displayed in
the lower right pane, and a Tcl array (more like a string-to-int map, if I
understand the code) with the names of the files selected in the file list.
The array is populated every time you click on a name in the file list, and
can contain multiple entries if you hold "Ctrl" while clicking.
> Could you summarize how FILENAME and FILENAMES work, please?
These are just environment variables set before running the tool command. They
are unset immediately after starting the command.
The tool command is unconditionally run using "sh -c <command>", so the
references to the environment variables are expanded by "sh".
Regards,
Alex
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
prev parent reply other threads:[~2016-06-28 8:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-27 13:21 [PATCH 1/2] Support for $FILENAMES in tool definitions Alex Riesen
2016-06-27 13:23 ` [PATCH 2/2] Ensure the file in the diff pane is always in the list of selected files Alex Riesen
2016-06-27 17:32 ` Jakub Narębski
2016-06-28 8:03 ` Alex Riesen
2016-06-27 15:49 ` [PATCH 1/2] Support for $FILENAMES in tool definitions Johannes Schindelin
2016-06-28 8:04 ` Alex Riesen
2016-06-27 17:28 ` Jakub Narębski
2016-06-27 17:53 ` Junio C Hamano
2016-06-27 18:09 ` Jakub Narębski
2016-06-28 8:54 ` Alex Riesen [this message]
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=20160628085421.GC3710@pflmari \
--to=alexander.riesen@cetitec.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
--cc=patthoyts@users.sourceforge.net \
/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;
as well as URLs for NNTP newsgroup(s).