<div dir="ltr">yeah, that's weird... what version of else you got? beta 36 was just released but it's still a secret</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter., 15 de dez. de 2020 às 06:34, Roman Haefeli <<a href="mailto:reduzent@gmail.com">reduzent@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey all<br>
<br>
I had a long IRC session yesterday trying to fix a problem with netpd<br>
on another user's computer. Finally, we were able to narrow down the<br>
issue to the behaviour of [else/dir] on Debian Buster being different<br>
from Ubuntu 20.04.<br>
<br>
On Ubuntu (and on Windows) feeding [dir] the path './' returns the<br>
content of the current directory of the patch. On Debian Buster, it<br>
returns the content of '/' instead. When feeding the path '.', on both<br>
Debian Buster and Ubuntu 20.04 the content of the current directory is<br>
listed (as expected).<br>
<br>
My specific problem might be worked-around by removing the trailing<br>
slash from any paths fed to [else/dir]. But I'm curious to understand<br>
how it is possible that the same compiled binary exhibits different<br>
results depending on Linux flavor. <br>
<br>
Check attached patch that demonstrates the problem on Debian Buster.<br>
<br>
Roman<br>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br>
</blockquote></div>