On Tue, 05 Jul 2016 04:57:56 +0000 Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote: DS> Feedback is sought for a proposed behaviour change to the shell. DS> DS> Currently, the ':a' word modifier removes '..' component from a path — DS> using a purely syntactic transformation, i.e., without consulting the DS> filesystem at all — and ':A' does the same and then resolves symlinks DS> [so no path component in the result is a symlink]. DS> DS> It has been proposed to change the semantics of :A to resolve symlinks DS> first and '..' components second, like the realpath(3) library function DS> does. DS> DS> Under the incumbent semantics, $foo:A denotes the same file as $foo:a DS> (but not necessarily the same file as $foo). Under the proposed DS> semantics, $foo:A denotes the same file as $foo (but not necesarily the DS> same file as $foo:a). DS> DS> Would this change be a good idea? Hello, I am not sure why would this be a good idea, the only argument for it I see is compatibility with realpath(), but how much does it really matter? There would seem to be quite a few flags/modifiers not corresponding to any C library functions, so this doesn't seem like such an egregious exception. But this change would be backwards incompatible, if only marginally, and my personal test for making breaking changes is whether I could see myself justifying them reasonably well to someone whose script has got broken after updating the shell. If you imagine yourself in such a situation, what would your explanation be? I don't think that "we decided to make it compatible with realpath(3)" quite cuts it. But this is just my personal opinion, of course (and, FWIW, I don't think I personally have any script which could be broken by this change anyhow). Regards, VZ
Attachment:
pgp2kYpRZCqeA.pgp
Description: PGP signature