Thank you for the eye opener, I have been using s6 daily for more than 7
years but never got too deep studying execline, I just dealt with having
services run right and once they did I just let them be.
I was working on a build chroot where no init or service supervision
exists, just minimal sw building tools, and I spent days trying to
figure out why the difference in behavior of the same script in chroot
than in my main system. There is much more than cd replacing coreutils
by execline so this means many scripts in the system may be affected by
the substitution. Even env is a different animal itself.
In any case, a new learning door has been opened.
Laurent Bercot:
>> As I discovered execline cd replaces the linux utility in a system and
>> produces peculiar results
>
> It doesn't really replace it. 'cd' is always a shell builtin. If there
> is a previous 'cd' binary on your system (Fedora still has one, maybe?),
> it is never used, and only there for compliance with a silly POSIX
> requirement.
>
> If you build execline with --enable-pedantic-posix, it can replace
> that binary, yes, but it will not replace the 'cd' command that is
> used by shell scripts.
>
>
>> On console cd seems to be perfect as expected
>
> If you include 'cd' in a command line in a way that it has to be an
> external command, it will work, whether in a terminal or in a script:
> $ env cd /etc ls
> will display the contents of /etc.
>
> If you just run
> $ cd /etc ls
> then cd is your shell builtin and it will only change your cwd to /etc,
> it will not run the ls command.
>
>
>> on script #!/bin/sh
>> when changing to a directory in a mounted partition it fails, while
>> normal cd works as if it is on a single partition.
>
> This has nothing to do with partitions, or glibc, or gcc, or anything.
> The only thing that can impact the result is whether or not a shell
> is interpreting your 'cd' command.
>
> You should never need to access execline's cd binary as the first link
> in a chainloading command line in a shell, since you can always use the
> "cd foobar && rest_of_command..." construction. But if for some weird
> reason you do, using "env cd" will do the trick.
>
> --
> Laurent
>
Received on Sat May 24 2025 - 04:12:13 CEST