All of lore.kernel.org
 help / color / mirror / Atom feed
From: "René Scharfe" <l.s.r@web.de>
To: "brian m. carlson" <sandals@crustytoothpaste.net>, git@vger.kernel.org
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH v4 1/2] abspath: add a function to resolve paths with missing components
Date: Mon, 7 Dec 2020 18:19:32 +0100	[thread overview]
Message-ID: <c1d1fe44-6a7d-3578-cd89-9aea59c4637a@web.de> (raw)
In-Reply-To: <20201206225349.3392790-2-sandals@crustytoothpaste.net>

Am 06.12.20 um 23:53 schrieb brian m. carlson:
> We'd like to canonicalize paths such that we can preserve any number of
> trailing components that may be missing.  Let's add a function to do
> that, allowing either one or an unlimited number of components to
> canonicalize, and make strbuf_realpath a wrapper around it that allows
> just one component.
>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---
>  abspath.c | 13 ++++++++++++-
>  cache.h   |  2 ++
>  2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/abspath.c b/abspath.c
> index 6f15a418bb..e6630b3618 100644
> --- a/abspath.c
> +++ b/abspath.c
> @@ -80,6 +80,17 @@ static void get_root_part(struct strbuf *resolved, struct strbuf *remaining)
>   */
>  char *strbuf_realpath(struct strbuf *resolved, const char *path,
>  		      int die_on_error)
> +{
> +	return strbuf_realpath_missing(resolved, path, 0, die_on_error);
> +}
> +
> +/*
> + * Just like strbuf_realpath, but allows specifying how many missing components
> + * are permitted.  If many_missing is true, an arbitrary number of path
> + * components may be missing; otherwise, only the last component may be missing.
> + */
> +char *strbuf_realpath_missing(struct strbuf *resolved, const char *path,
> +			      int many_missing, int die_on_error)

So this uses two 32-bit values to pass two bits.  Hmm.

I find the concept of a "real" path with imaginary components strangely
amusing.  But perhaps a name like strbuf_resolve_path() would fit better?

>  {
>  	struct strbuf remaining = STRBUF_INIT;
>  	struct strbuf next = STRBUF_INIT;
> @@ -129,7 +140,7 @@ char *strbuf_realpath(struct strbuf *resolved, const char *path,
>
>  		if (lstat(resolved->buf, &st)) {
>  			/* error out unless this was the last component */
> -			if (errno != ENOENT || remaining.len) {
> +			if (errno != ENOENT || (!many_missing && remaining.len)) {
>  				if (die_on_error)
>  					die_errno("Invalid path '%s'",
>  						  resolved->buf);

So the original code errors out if there is a real error
(errno != ENOENT).  It also errors out if any component except the last
one is missing (errno == ENOENT && remaining.len); that's what the
comment is about.  This patch adds the ability to ignore ENOENT for all
components.

Perhaps convert many_missing and die_on_error into a single flags
parameter and implement the flags DIE_ON_ERR and REQUIRE_BASENAME or
similar?  Callers would be easier to read because such an interface is
self-documenting -- provided we find good flag names.

> diff --git a/cache.h b/cache.h
> index e986cf4ea9..a1386235fc 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -1320,6 +1320,8 @@ static inline int is_absolute_path(const char *path)
>  int is_directory(const char *);
>  char *strbuf_realpath(struct strbuf *resolved, const char *path,
>  		      int die_on_error);
> +char *strbuf_realpath_missing(struct strbuf *resolved, const char *path,
> +			      int missing_components, int die_on_error);
>  char *real_pathdup(const char *path, int die_on_error);
>  const char *absolute_path(const char *path);
>  char *absolute_pathdup(const char *path);
>


  parent reply	other threads:[~2020-12-07 17:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-06 22:53 [PATCH v4 0/2] rev-parse options for absolute or relative paths brian m. carlson
2020-12-06 22:53 ` [PATCH v4 1/2] abspath: add a function to resolve paths with missing components brian m. carlson
2020-12-07  0:02   ` Eric Sunshine
2020-12-07  2:11     ` brian m. carlson
2020-12-07 17:19   ` René Scharfe [this message]
2020-12-08  2:51     ` brian m. carlson
2020-12-06 22:53 ` [PATCH v4 2/2] rev-parse: add option for absolute or relative path formatting brian m. carlson
2020-12-07  0:30   ` Eric Sunshine
2020-12-07  2:38     ` brian m. carlson

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=c1d1fe44-6a7d-3578-cd89-9aea59c4637a@web.de \
    --to=l.s.r@web.de \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.