On Wed, Nov 12, 2025 at 08:18:34PM -0600, Glenn Washburn wrote:
> On Wed, 12 Nov 2025 21:39:09 +0100 > Daniel Kiper <[email protected]> wrote:
> > On Sun, Nov 09, 2025 at 04:31:52PM -0600, Glenn Washburn wrote:
> > > The script assumes that it is run from the root of the source tree,
> > > which is where it is located. So this should be enforced to prevent
> > > accidental misuses.
> > >
> > > Signed-off-by: Glenn Washburn <[email protected]>
> > > ---
> > > linguas.sh | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/linguas.sh b/linguas.sh
> > > index b95ad4f7d9c2..45cdf2ac14ac 100755
> > > --- a/linguas.sh
> > > +++ b/linguas.sh
> > > @@ -1,5 +1,10 @@
> > > #!/bin/sh
> > >
> > > +SDIR=$(realpath -e "$0")
> >
> > SDIR=$(readlink -f "$0")
>
> I'm curious, why do you prefer this? On Debian they both come from the
> coreutils package. They both resolve symlinks, so functionally I
> believe they are the same. According to the Debian readlink man page,
> "Note realpath(1) is the preferred command to use for canonicalization
> functionality." I find the name a little more intuitive, as we want the
> real path and the argument might not be a link to be read, which is
> what readlink suggests to me. Is readlink an older util, and thus more
> widely supported?
When I was resolving the same problem years ago there wasn't such note
in the readlink(1) man. However, if it is there right now then I think
it makes more sense to use realpath instead. Though I think you should
mention in the commit message why you chose it instead of readlink.
> > > +SDIR=${SDIR%/*}
> >
> > SDIR=$(dirname "$SDIR")
>
> Also, why this is preferable? My guess is that it is more
> readable. I chose the pure shell approach because its one less exec and
Yep...
> external binary dependency. That syntax is supported on both sh and
> dash, so I expect wide compatibility.
I think it does not matter much here. However, if you prefer shell
approach please explain your choice in the commit message.
Daniel
_______________________________________________
Grub-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/grub-devel
