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

[Lawrence Velázquez <larryv@xxxxxxxxxxxx>]

> On Sep 25, 2016, at 2:17 AM, Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx> wrote:
> 
> On 25 September 2016 at 07:17, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>> However, neither that nor any of your suggestions would accomplish
>> altering the filename based on the file content.  The file has to be
>> created in the parent shell before the command is even run, so that
>> it can be opened as the command's output; and I would not advocate
>> having the shell peering at the content without being explicitly
>> scripted to do so.
> 
> Yes yes I was surprised my post could be understood as peering at
> content. It's like in the git example: extension is known (is obtained
> from git ls-tree, just like SHA of the BLOB), and can be provided to
> =( ) which runs command that accesses the content. Other example:
> downloading a HTTP address, having Content-Type available, knowing
> what the extension should be.

According to Bart, the parent shell has to create the temporary file
before executing the command inside the subshell. Unless I'm mistaken,
that implies that the parent would have to inspect said command before
executing it in order to decide how to obtain your suggested metadata.
If the subshell contains "git cat-file", the parent shell would have to
know to run "git ls-tree". If the subshell contains "curl", the parent
shell would have to know to run "curl -I" first.

Guessing an extension by peering at arbitrary, context-specific metadata
is no better than doing so by peering at the data itself. It's just
another form of content detection that would balloon into a convoluted
mess and shouldn't be implemented in the shell itself.

> And a standard situation: creating specific content for specific
> program expecting specific, known extension

Would Bart's TMPSUFFIX suggestion satisfy this use case?

> (a case if only it's not typical and of course common less program,
> it's part of my point in general: "what programs do not use
> extensions?").


I could spend all day (or at least a minute!) listing Unix programs that
don't care about extensions. This is really not a good argument.

vq