Man who thought opening a TXT file is fine thought wrong

Post by exikyut » Sat, Apr 03, 2021, 11:18 AM UTC

tetha wrote: post #203

bawolff wrote: post #145

Earlier quoted context omitted.

> ...but the fact that file:// schemes can access remote files by appending /net/ followed by a domain name is pretty shocking. Not that shocking. Windows has had that with SMB networking for ages file://SMBSERVERNAME/path/file . Linux somewhat supports /dev/tcp/HOSTNAME/PORT (technically that's application level in bash so not everywhere), and im sure there's daemons you could run to automount things on the fly.

> Linux somewhat supports /dev/tcp/HOSTNAME/PORT (technically that's application level in bash so not everywhere), and im sure there's daemons you could run to automount things on the fly. Do note that this has been disabled in the major distributions at compile time for pretty much ever. The debian bug to build bash with that feature by default is ~20 years old (and was closed as wontdo).

  Terminal 1
  $ echo hi > /dev/tcp/127.0.0.1/9999

  Terminal 2
  $ nc -vvvlp 9999
  Listening on [0.0.0.0] (family 2, port 9999)
  Connection from 127.0.0.1 57540 received!
  hi
  $

Post by TazeTSchnitzel » Sat, Apr 03, 2021, 11:58 AM UTC

sammax wrote: post #214

> I found another browser trick that lets force-downloaded TXT files to be opened without user interaction or warning I wish there was more elaboration on this. Opening a downloaded file without user interaction sounds pretty bad.

Post by kevinoid » Sat, Apr 03, 2021, 12:30 PM UTC

tetha wrote: post #203

bawolff wrote: post #145

Earlier quoted context omitted.

> ...but the fact that file:// schemes can access remote files by appending /net/ followed by a domain name is pretty shocking. Not that shocking. Windows has had that with SMB networking for ages file://SMBSERVERNAME/path/file . Linux somewhat supports /dev/tcp/HOSTNAME/PORT (technically that's application level in bash so not everywhere), and im sure there's daemons you could run to automount things on the fly.

> Linux somewhat supports /dev/tcp/HOSTNAME/PORT (technically that's application level in bash so not everywhere), and im sure there's daemons you could run to automount things on the fly. Do note that this has been disabled in the major distributions at compile time for pretty much ever. The debian bug to build bash with that feature by default is ~20 years old (and was closed as wontdo).

Post by kergonath » Sat, Apr 03, 2021, 12:38 PM UTC

tsimionescu wrote: post #194

cyphar wrote: post #120

Earlier quoted context omitted.

Well, on Unix file extensions are a convention and don't have any strict semantic meaning. Maybe this doesn't make sense in a world where most people do think in terms of file extensions (thanks to the popularity of Windows) but it shouldn't be surprising that non-Windows programs might not special-case file extensions. (Though in fairness, text editors do usually have special casing for file extensions and these day…

This is only a Unix vs Windows thing in terms of the application launcher and how it is implemented. File extensions are semantically meaningful for many unix tools, most notably gcc.

Post by kergonath » Sat, Apr 03, 2021, 12:41 PM UTC

A4ET8a8uTh0 wrote: post #110

userbinator wrote: post #56

Two words: excessive complexity. It's always seemed strange that an application called TextEdit is actually more than a text editor. I strongly believe that content-type autodetection, much less HTML rendering(!), most certainly does not belong in a text editor.

I think this captures my sentiment on the matter as well. Applications today want to be a swiss army knife and do just about every job.. and do it poorly. I do expect that level of complexity from RStudio, but probably not from Notepad. I would probably kinda accept it in Notepad++. So real question. Is TextEdit a default text editor in a mac?