<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 12, 2023 at 3:36 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 1/12/23 16:19, enh wrote:<br>
> <br>
> <br>
> On Thu, Jan 12, 2023 at 1:40 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>> wrote:<br>
> <br>
> On 1/11/23 16:53, enh wrote:<br>
> > ah, which is probably because you won't typically have $PWD set on Android...<br>
> ><br>
> > // If this isn't an absolute path, start with cwd or $PWD.<br>
> > if (*path != '/') {<br>
> > if ((flags & ABS_KEEP) && (str = getenv("PWD")))<br>
> > splitpath(path, splitpath(str, &todo));<br>
> > else {<br>
> > splitpath(path, splitpath(str = xgetcwd(), &todo));<br>
> > free(str);<br>
> > }<br>
> <br>
> Which would explain the behavior difference, yes: getcwd() asks the OS for the<br>
> current path to "." which is always going to be fully resolved, which means<br>
> peeling off one member gives us the observed output.<br>
> <br>
> > } else splitpath(path, &todo);<br>
> ><br>
> > mksh fakes it so `echo $PWD` works, but there's no _exported_ $PWD:<br>
> <br>
> It's not faking it, it's setting the shell variable. But bash exports PWD by<br>
> default (and thus so does toybox), but mksh doesn't.<br>
> <br>
> Toysh implemented the bash behavior and mksh... is mksh:<br>
> <br>
> $ env -i bash --noprofile --norc -c 'declare -p PWD'<br>
> declare -x PWD="/home/landley/toybox/toybox"<br>
> $ env -i ./sh --noprofile --norc -c 'declare -p PWD'<br>
> declare -x PWD="/home/landley/toybox/toybox"<br>
> $ env -i mksh --noprofile --norc -c 'declare -p PWD'<br>
> mksh: mksh: --: unknown option<br>
> <br>
> I added an "export PWD" to the test, does that fix it?<br>
> <br>
> yeah, that passes for me locally. thanks!<br>
> <br>
> worth adding explicit PWD-unset tests for the other codepath, since it exists?<br>
<br>
Ooh that's a pointy question. I'm not sure you knew how pointy when you asked<br>
it. The answer is probably "no because TEST_HOST should not become a conceptual<br>
forkbomb"?<br></blockquote><div><br></div><div>not at all :-)</div><div><br></div><div>all i was thinking was "hmm... since Android's default shell doesn't export PWD, the currently-untested case is our default case".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The problem is the behavior varies: bash and mksh are different,<br>
gnu/toybox/busybox are different, filesystems give different behavior... I don't<br>
want the tests to be more brittle than necessary in the absence of a spec. I'm<br>
testing for "correct" behavior and testing error paths reject "incorrect"<br>
behavior, but this is imprecisely defined fallback behavior that could change if<br>
a better option shows up.<br>
<br>
We're already in a "toyonly" test because gnu/realpath is doing getcwd() rather<br>
than $PWD for expanding relative paths, and my plumbing is going "if it's told<br>
not to expand symlinks then use $PWD instead of getcwd() to expand relative<br>
paths when available, falling back to the other when it isn't. (Which seems to<br>
be to be the "more correct" behavior, in the absence of an actual spec that<br>
covers this stuff.) If there was an additional way to get $PWD when the variable<br>
wasn't set, it probably should, because -s asks it to.<br>
<br>
By the way, the NEXT hair-splitting corner case here is that toysh will export<br>
PWD from its internal list variable list into environ where getenv() can find it<br>
even when running builtins, but NOT when running NOFORK commands. Those have to<br>
use getvar() instead of getenv() to see current variable values.<br>
<br>
I was initially doing export on assignment instead of export on fork and it<br>
turns out bash's nested local variable semantics require export on fork. You can<br>
export a local variable, have the next nested function call unset its own local<br>
of the same variable to create a "whiteout", and then the function call after<br>
that declare a local variable that isn't exported:<br>
<br>
$ x() { local X=potato; declare -p X; }; y() { local X; unset X; declare -p X;<br>
x;}; z() { local X=fruit; export X; y; declare -p X; }; z<br>
declare -- X<br>
declare -- X="potato"<br>
declare -x X="fruit"<br>
<br>
So anyway, the xabspath() fallback path is doing the best it can in the absence<br>
of complete information, and I'm not comfortable defining "fail in this way" as<br>
the SPECIFIC best it can do? If more sources of information become available,<br>
should it NOT use them? If xrealpath() did wind up getting called from inside<br>
the shell, then possibly it would need to learn about getvar() and the local<br>
version of PWD. (Or just have a wrapper function layer with the real one growing<br>
another argument to pass PWD through...)<br>
<br>
There's a reason all this stuff was in pending for so long...<br></blockquote><div><br></div><div>given how hairy this is (and most people are probably expecting PWD to be exported), i wonder whether i should change the default mksh rc file to include `export PWD`. that's a break with the past, but a potentially useful dose of consistency generally...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
<br>
P.S. It would be GREAT if an actual standard was on this level, but it isn't.<br>
</blockquote></div></div>