7 ms·

I agree that it may be possible to implement this feature in a nice form where it makes sense (for the people who need it). But it seems really strange to me a

I agree that it may be possible to implement this feature in a nice form where it makes sense (for the people who need it). But it seems really strange to me and I cannot imagine a use for it. Conceptually, the shell only sees the contents of the script, why would it act differently according to where the script is? When you open a jpeg image, the jpeg library does not provide a facility to recover the directory where that file was found. For all you know, this may be an in-memory jpeg. Isn't the same with shell scripts?

deleted 5y ago
[deleted]
coldtea 5y ago
>Conceptually, the shell only sees the contents of the script, why would it act differently according to where the script is? Doesn't need to act differently in what it does. But it does need to report it, because e.g. you might want to bundle data/assets/config relative to the script, and want to be able to run it from wharever and have it still be able to find it.
- WildcardWiz 5y ago
  It's an interesting question. In most shell, it is possible to "source" a given file, which basically is a form of file inclusion. How should the script location feature behave in that situation? Should it report the sourced file location, or the sourcing one? In the later case, does it mean that it is not possible to write reusable code based on that feature? In the former case, what should be done when sourcing is done recursively? Can this be used to defeat file location, for instance, by generating a script in /tmp and sourcing another file from it?
oblio 5y ago
First of all: https://en.wikipedia.org/wiki/Argument_from_incredulity https://en.wikipedia.org/wiki/Argument_from_incredulity Secondly, it's super frequent that scripts I write or that others write need the folder they're executed in as an argument. 99% of scripts I've seen aren't meant to be piped to. They're just launched as simple, dumb, standalone "programs".

deleted 5y ago

[deleted]

coldtea 5y ago

>Conceptually, the shell only sees the contents of the script, why would it act differently according to where the script is? Doesn't need to act differently in what it does. But it does need to report it, because e.g. you might want to bundle data/assets/config relative to the script, and want to be able to run it from wharever and have it still be able to find it.

WildcardWiz 5y ago
It's an interesting question. In most shell, it is possible to "source" a given file, which basically is a form of file inclusion. How should the script location feature behave in that situation? Should it report the sourced file location, or the sourcing one? In the later case, does it mean that it is not possible to write reusable code based on that feature? In the former case, what should be done when sourcing is done recursively? Can this be used to defeat file location, for instance, by generating a script in /tmp and sourcing another file from it?

oblio 5y ago

First of all: https://en.wikipedia.org/wiki/Argument_from_incredulity https://en.wikipedia.org/wiki/Argument_from_incredulity Secondly, it's super frequent that scripts I write or that others write need the folder they're executed in as an argument. 99% of scripts I've seen aren't meant to be piped to. They're just launched as simple, dumb, standalone "programs".