Re: Feature request: set extension for =( ) created file

["Nikolay Aleksandrovich Pavlov (ZyX)" <kp-pav@yandex.ru>]

25.09.2016, 02:04, "Sebastian Gniazdowski" <sgniazdowski@gmail.com>:
> On 24 September 2016 at 21:55, Lawrence Velázquez <larryv@macports.org> wrote:
>>>  On Sep 24, 2016, at 3:30 PM, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
>>>
>>>  What vim does is a fancy ignorable thing for some, what other program
>>>  might do might not be. Extensions are vital parts of file names.
>>
>>  Not really. Any competently written program that cares about the
>>  structure of its input has some other way of validating said structure,
>>  like actually parsing it or checking for a file signature / header
>>  / magic number. Programs that process stdin already have to do this.
>
> Yeah, one of such programs is Vim and it fails recognizing e.g.
> ctags/awk.c as ft=zsh.
>
>>>  Extension-aware =( ) would be a masterpiece feature for Zsh, though,
>>>  IMO.
>>
>>  Unless it were implemented using libmagic or something, I would consider
>>  it a massive waste of time and effort.
>
> What time and effort? I guess it can be a beautiful few lines patch.
> Modify name of file? Something like strcat. Parsing clever syntax that
> would provide the extension? Also possibly basic.
>
> Best regards,
> Sebastian Gniazdowski

I would consider another thing: while extensions are significant part of the file names, sometimes complete last path component or the whole path matters. I would suggest that if syntax is extended to allow controlling some properties of a temporary file name it should allow to control everything:

1. Provide just an extension: use names like `/tmp/zshUkxFmK.ext`.
2. Optionally provide full file name: use names like `/tmp/zshUkxFmK/name.ext`, in this case temporary directory is generated and then recursively deleted.
3. Provide full path: allow generating automatically removed temporary files at any selected location.
4. Optionally make this feature generate temporary directories and not files, if code for 2. is written this should be easy.

The key point is that I sometimes need temporary file in a specific location, but I almost never needed temporary file with a specific extension.

Currently `echo =(echo foo).bar` produces something like `/tmp/zshUkxFmK.bar` which is not very useful because this file does not exist. I would thus suggest extending syntax in one of the following ways:

1. `=(cmd).bar` produces the same thing it does now, but file does exist. `=(cmd):bar` results in `/tmp/zshUkxFmK/bar`. `=(cmd)=bar` uses `./bar` as a temporary file (`=(cmd)=/bar` uses `/bar`, of course).

   This is backwards incompatible: if some people use this “feature” (e.g. in Vim it is possible to implement BufReadCmd which reads `/tmp/zshUkxFmK` when receiving `/tmp/zshUkxFmK.bar`) their scripts will be broken.
2. Currently `=(cmd)(…)` acts like a usual glob expression: `=(cmd)` is replaced with `/tmp/zshUkxFmK` and then `(…)` applies (e.g. `=(cmd)(/)` will yield “zsh: no match” because produced file is not a directory). Since such syntax is an error in most cases I would suggest to reuse this: `=(cmd)(.bar)`: extension, `=(cmd)(bar)`: exact file name in /tmp, `=(cmd)(/bar)`: absolute file name, `=(cmd)(./bar)`: file name in the current directory. Specifically:

   - `({xxx})` is treated as a part of the file name under /tmp if first character in `{xxx}` is not a dot or slash
   - `(.{xxx})` is treated as an “extension” if first character in `{xxx}` is not a dot or slash
   - in all other cases it is treated like a regular glob expression like if it was after `>`; program will receive whatever glob was expanded to.

   As an implementation detail I would expect zsh to run parameter expansion, filename expansion and filename generation and match the result according to the above patterns.

In both options if path ends with `/` then it is considered a temporary directory and is an error unless invoked with empty command (this is parse error now).