Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

Come to think of it, you could abuse NTFS Alternate Data Streams for this.

Imagine:

  > # See alternate data streams
  > Get-Item diagram.dot -Stream *
  Stream         Length
  ------         ------
  :$DATA             123
  text/plain        4444
  image/svg+xml    65432
  image/png       456134

  > # Send the whole bulk
  > Get-Item diagram.dot -Stream * | ...

  > #... or pick just one:
  > Get-Content diagram.dot -Stream "image/svg+xml" | Send-Email ....

Would have to ensure everything is aware of the streams and the convention, though, so that you wouldn't accidentally truncate them when copying files around.

View on HN

Not just NTFS, but pre OSX Macs would do stuff like this. Like a formatted document would have a text/plain fork, and the formatting information in another fork. Or an executable could keep it's symbol table or relocation information in other forks.

Thanks! I just checked, and it seems that ADS were introduced in NTFS in order to support Mac resource forks.

https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(AD...

You can muck around alternate data streams like a classic resource fork of a file on macOS by appending

   /..namedfork/rsrc

to the file name.

   ls ./groovyFontFile/..namedfork/rsrc

https://stackoverflow.com/a/42216808/8878480

I've tried it with ancient font suitcases -- the ones that pre-date dfont (data fork only) fonts.

It's somewhat ironic that all desktop file systems these days support myriad data streams on a file. I've implemented some on NTFS, played with extended attributes across tar archives between Linux and Mac and Windows. It's all there, but no longer used.

Ah, that's interesting, thanks for mentioning it. That's pretty much what I mean, but on arbitrary file descriptors instead of files.

I agree that both ends need to be aware of these extra formats to make use of them, but just like with clipboards, programs could always fall back to pretending only text/plain exists :)

Typing, in the programming language sense, is a major can of worms that a general purpose shell usually avoids with a deliberately bare bones type system (e.g. text, binary, directory and symlink).

How can a shell do anything serious with asserted file types that can be missing, wrong, malformed, unknown or mendacious? It's hard to go beyond offering a best-effort "open with the associated program" application as an alternative to vi, cat etc.

> How can a shell do anything serious with asserted file types that can be missing, wrong, malformed, unknown or mendacious? It's hard to go beyond offering a best-effort "open with the associated program" application as an alternative to vi, cat etc.

How would that be any worse than the status quo, though?

Programs already output, depending on their invocation and the utility at hand, binary data in arbitrary formats, shell escape sequences, text, ASCII art, etc.

The only issue I can think of is for portability of the scripts, if a program gets updated to support a new type as input or output, and that causes issues compared to the testing environment. But that's arguably already an issue too, and it would be rather simple to annotate expected types.

The cost of specifying MIME types or the like can easily exceed its value, which is very low because we are already specifying file types (to applications that can deal with more than one) well enough with file extensions (undependable, but vastly more convenient than new infrastructure for new metadata), with self-describing or recognizable file formats, and often explicitly.

Reply on news.ycombinator.com