bug#68074: closed (eshell sudo/doas does not work for aliases)

[GNU bug Tracking System]

Your message dated Sat, 27 Jan 2024 12:24:46 -0800
with message-id <e8c9cdd3-ba88-4334-869f-5f2b79fd1ca2@gmail.com>
and subject line Re: bug#68074: eshell sudo/doas does not work for aliases
has caused the debbugs.gnu.org bug report #68074,
regarding eshell sudo/doas does not work for aliases
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
68074: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68074
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: eshell sudo/doas does not work for aliases Date: Wed, 27 Dec 2023 21:12:26 +0000 (UTC)

sudo/doas does not give the expected permissions when using an eshell alias:

When no alias has been defined:

~ $ which cp
eshell/cp is a native-compiled Lisp function in ‘em-unix.el’.
~ $ touch test
~ $ cp test /boot/efi/
Opening output file: Permission denied, /boot/efi/test
~ $ sudo cp test /boot/efi/
~ $ echo $?
0

But after defining the alias:

~ $ alias cp '*cp $*'
~ $ which cp
cp is an alias, defined as "*cp $*"
~ $ sudo cp test /boot/efi/
/usr/bin/cp: cannot stat '/boot/efi/test': Permission denied

I have attached a patch with a possible fix.

0001-lisp-eshell-em-alias.el-eshell-maybe-replace-by-alia.patch
Description: Text Data

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#68074: eshell sudo/doas does not work for aliases
>
>
>
>
> Date: 
>
> Sat, 27 Jan 2024 12:24:46 -0800
>
>
>
>
> On 1/27/2024 12:46 AM, Alfonso Sanchez-Beato via Bug reports for GNU 
> Emacs, the Swiss army knife of text editors wrote:
> >   En sábado, 27 de enero de 2024, 01:19:32 GMT, Jim Porter 
> > <jporterbugs@gmail.com> escribió:
> > > ... actually, this is a more-complete patch. I'm not 100% sure about
> > > this part though:
> > >
> > >    ',(car args)
> > >
> > > That (usually) creates something like (quote "command"), but it's safer
>
> I thought about this some more and the extraneous quoting is fine in my 
> opinion. Eshell already does that quite a bit in 'eshell-do-eval', so 
> what's one more case?
>
> > This last patch works nicely, thanks a lot! It works also in cases where my 
> > patch was not, like:
> >
> > $ eshell/sudo VAR=val <alias> ...
>
> Wait, that works?! (After trying it out locally, so it does!)
>
> Looking at the code, I see why now: 'eshell-named-command' calls 
> 'eshell-prepare-command-hook', and that hook is where we handle local 
> variables. However, I truly didn't expect that; I thought the local 
> variable handling occurred in an earlier phase. The more you know...
>
> Anyway, since this works even better than I'd expected, I've now merged 
> my patch to the master branch as 3c680968e49. Closing this bug now.
>
>
> --- End Message ---