[–]▶ No.809304>>809443 [Watch Thread][Show All Posts]
As a quite experimented POSIX sh user (kill me), I'm trying to understand why POSIX did (and still) authorize newlines in filenames without standardizing the GNU extensions to allow the use of \0 as a separator for all coreutils/findutils/sed/etc...
I mean, what am I supposed to choose between shitting the bed with such files or using GNU specific stuff (also, fuck most *BSDs for not following)?
Anyone found a better solution to this shit?
▶ No.809321>>809328
You put filenames in an array. POSIX sh has arrays. Well, one array. It's "$@".
Alternatively, you could maybe encode all filenames in base 16 or base 64.
The real answer is that traditional Unix people aren't interested in writing correct software. If it works most of the time that's enough. When it crashes, you holler down the hall "hey, reboot it". Reliability is for other people.
https://www.jwz.org/doc/worse-is-better.html
Unix is a disease.
▶ No.809328>>809333 >>809367 >>809426
>>809321
>use $@
I know of that trick, but it's simply too cumbersome.
>UNIX hate
1) POSIX isn't UNIX; they standardized a lot of useful shit.
2) The UNIX philosophy is mostly sound, even if the implementation was a big hack.
3) What do you propose?
In fine, I just use the GNU stuff. A least, it works.
▶ No.809333>>809367
>>809328
>1) POSIX isn't UNIX; they standardized a lot of useful shit.
POSIX is closer to being correct than Unix. If something is missing from POSIX, like here, expect it to be missing from Unix as well.
>2) The UNIX philosophy is mostly sound, even if the implementation was a big hack.
I think it takes minimalism too far. You could make it decent with only minor changes, though.
>3) What do you propose?
GNU's approach from the start instead of patching over the holes for compatibility's sake. GNU is better than Unix. Unix designed from the ground up with GNU's approach to correctness would be even better than that.
▶ No.809367>>809371 >>809388 >>809393
>>809328
>>809333
UNIX can't be made good or decent. The kernel, C, the shell, every command, every library function, every system call, every directory path, the whole philosophy, it's all cancer. And that includes GNU and Plan 9 too. Anything remotely good about UNIX was stolen from Multics.
▶ No.809371>>809410 >>809431
>>809367
>durr everything is shit
hmm good point anon
▶ No.809388>>809410
>>809367
Surprised you didn't blame the Jews for the von Neumann architecture.
▶ No.809393>>809410
>>809367
Wow great argument fagtron you sure convinced me with those hot opinions.
▶ No.809410>>809412 >>809425
>>809371
>>809388
>>809393
Everything in UNIX is shit. Believe it or not, there are operating systems that aren't made by Bell Labs or based on UNIX or written in C.
I'm not going to waste time explaining why C is shit or why all the commands are so inconsistent or why the shell treated as a "scripting language" is worse than PHP or why GNU "correctness" isn't correct at all. It doesn't take a rocket scientist to see that these things are all crap despite the standardization and over 40 years of "improvements".
▶ No.809412>>809416
>>809410
> there are operating systems that aren't made by Bell Labs or based on UNIX
Everyone knows that, but can you name one that is a viable alternative to the current crop?
▶ No.809416>>809420
>>809412
>inb4 he says BSD
I just love his arguments there's nothing besides he think it's shit it would bloody help us to understand his view tho.
▶ No.809420>>809464
>>809416
Well he's ruled out BSD because based on "SHITTY BELL LABS UNIX C". I'm expecting he'll come back and name some obscure realtime OS that is very special purpose and not viable as an alternative.
▶ No.809424
fuck POSIX, use windows instead
▶ No.809425>>809433
>>809410
I used to wonder where this "everything considered as harmful" shit came from.
Then I remembered pic related.
>first day at MIT, yay I'm gonna be a computer
>hey class let me tell you why everything you don't even know yet is wrong you fucking retards. computers are wrong, science is wrong, calculus is wrong, everything is wrong, the world is shit you should've killed yourselves when you had the chance
That's right it was the self-hating lispers. Parentheses never lie.
▶ No.809426
>>809328
>2) The UNIX philosophy is mostly sound
(It isn't.)
▶ No.809431
>>809371
>>durr everything is shit
Lisp was good, it still is good. You'll never run into the "my filename has a newline character in it so now my software thinks it's too filenames" problem when using lisp because Lisp has proper strings not newline deliminated nonsense.
Unix won because it was cheap, because the US Government forbade AT&T from selling it because they had a telephony monopoly. There was no philosophy underpinning it, only "this hardware sucks, maybe we'll write some software that sucks too since the hardware isn't worth anybody spending real time developing proper software"
Later generations forgot or never learned this, so they think Unix was always hot shit because it was better than DOS. Retards, all of you.
▶ No.809433>>809439 >>810873
>>809425
It's a hard pill to swallow, but it's true. Everything went to shit when Lisp lost to Unix. The fall of Lisp was much like the fall of Rome in many respects. We're living in a dark uncultured age of computing.
▶ No.809440>>809442 >>809502
>>809439
So use another CL implementation retard. Or even better, use a scheme dialect.
▶ No.809442>>809446 >>809502
>>809440
Scheme is godlike yes, but again, I'm still waiting for the alternative to Unix based / created in C.
▶ No.809443>>809448 >>809459
>>809304 (OP)
>Anyone found a better solution to this shit?
How about a filesystem where you can't name any file con.foo or aux.bar (Windows 10), or one that silently mangles unicode into a different byte representation (Mac OS 10)?
▶ No.809446>>809456
>>809442
Unix sucked all the air out of the room, suffocated all the competition. Nothing could compete with free and shitty but technically works most of the time.
I mean for fucks sake, just look at how many post-C languages gave themselves terrible C-inspired syntax for no reason other than C was popular and they wanted to go with the flow.
▶ No.809448>>809457 >>809459
>>809443
>you can't name any file con.foo or aux.bar (Windows 10)
Just trying to imagine what technical justification might exist for such an arbitrary limitation sends shivers down my spine.
▶ No.809456>>809458 >>809466
>>809446
C syntax is fucking brilliant.
▶ No.809457>>809459 >>809467
>>809448
The file extension doesn't matter. It's just con and aux. And it's because Windows itself doesn't want you naming files after device nodes (CON and AUX)
▶ No.809458
>>809456
Although I do prefer Go syntax, excluding the braces on one-line if statements
▶ No.809459
>>809448
>>809457
>>809443
Also it is possible to force the creation of these files and nothing happens so it's probably just for some bullshit legacy or security reasons
▶ No.809464>>809510
>>809420
Watch. I'm betting he comes back with Windows.
▶ No.809466>>809484
>>809456
It's moronic, and the gross inadequacy and ugliness of the C preprocessor proves it. It only becomes even worse when you try to use it in languages with more complex grammars. Just look at C++. Absolute trash.
▶ No.809467>>809469
>>809457
>it's because Windows itself doesn't want you naming files after device nodes (CON and AUX)
Why are they trying to prevent that?
▶ No.809469>>809471
>>809467
Because some other OS they ripped off their FS design from 35 years ago had device files
▶ No.809471>>809490
>>809469
Linux/Unix don't have device files?
▶ No.809484
>>809466
C++ language has great semantics, I like using them. The problem is that when I get to that level of C++ programming, it's probably easier and more reliable to use a language that wasn't designed to be backwards compatible with a very old language. My preference is Scheme but I prefer to use Java over C++.
▶ No.809490>>809505
>>809471
Linux never stopped me from creating a file named sda1....
▶ No.809502>>809506 >>809514
>>809440
>>809442
>Scheme
>godlike
You are now aware that undelimited call/cc is an abomination and the functional equivalent of goto. It's also a feature of Scheme.
▶ No.809505
>>809490
Linux adopted an already established filesystem structure. Windows has to deal with legacy crap
▶ No.809506
>>809502
All schemes worth a shit support delimited continuations. You also talk like a redditor NSA faggot.
▶ No.809510
>>809464
I'm now predicting that he has nothing to offer, other than act like a contrarian attentionwhore.
▶ No.809514>>809519
>>809502
Use racket, it's got deliminated continuations. They're very nice.
Also:
>bitching that scheme lets you use continuations which are "like goto"
>when C has goto (and setjmp/longjmp for that matter...)
>and C makes you do manual memory management
>and when C allows all manner of unsafe operations
>and when C is packed full of undefined behavior
>and C allows countless unsafe
It's popular to talk smack about lisp and scheme giving the programmer too much power, but in a discussion about Unix/C, that's a laughable angle. C gives you more than enough rope to hang yourself, but that's excused because with that rope comes a lot of power if you use it properly. Continuations (and for that matter, macros) are the same. They give programmers the opportunity to tie themselves in knots but they're also immensely powerful, particularly when the two are combined...
▶ No.809519>>809520 >>809526
>>809514
I don't use C. In fact, I hate C. My complaint is more that Scheme (and other functional languages) hold undelimited call/cc up like it's some awesome powerful brilliant control structure when it's dangerous garbage. Not fond of dynamic scoping in Common Lisp either.
▶ No.809520>>809527
>>809519
Don't use it then, no one is forcing you to.
▶ No.809525>>809531
The greatness of a programming language comes down to how the programs written in run on current hardware.
Functional programming languages are generally slower than imperative languages on current hardware, and thus inferior.
▶ No.809526>>809529
>>809519
> it's some awesome powerful brilliant control structure
It is.
>control structure
More to the point, it facilitates the creation of your own control structures.
>it's dangerous
Easy to abuse or misuse, sure. Dangerous? I think you'll survive...
>garbage
Powerful and brilliant.
>Not fond of dynamic scoping in Common Lisp either.
Common Lisp has lexical scoping and dynamic scoping. Normal variables in CL are lexically scoped, as in scheme. "Special" variables are dynamically scoped. Lexical scoping is plainly superior in most cases, though dynamic scoping does have it's uses. I greatly prefer the way Racket handles this, all variables are lexically scoped but there is "parameters" that provide dynamic binding (https://docs.racket-lang.org/reference/parameters.html) Historically dynamic binding came first, which is probably most of the reason CL.
▶ No.809527>>809528
Most people like C but are unable to explain why. I found out through intensive introspection lel that the only thing that makes it superior is that it has the PERFECT abstraction level.
That may look unimportant compared to stuff like syntax or UBs, but it is crucial.
The Lisp circlejerking is pretty impressive in here, by the way.
>>809520
>just use C++ as C with classes so its horrible bloat doesn't exist
>you'll never have to read code you didn't make
You know you're wrong and retarded.
My thread went a strange way.
▶ No.809528
>>809527
I was takling about call/cc, but carrying on this thread with you seems like a waste of time.
▶ No.809529>>809532
▶ No.809531>>809534
>>809525
You know nothing. Lisp compilers that produce machine code competitive with C have existed since the 80s and are still competitive today.
The "high level or fast" meme is a false dichotomy perpetuated by fools. "C is low level and fast, Perl is high level and slow, therefore this must be a rule of nature" Absolute shit. The truth of the matter is that C was actually very resistant to optimization; optimizing compilers for C didn't start to get good until the fucking 90s. Before then, if you were writing "fast C code" you were writing 90% assembly language wrapped with C's function syntax. Optimizing compilers existed for better engineered languages decades before C proper got fast. But they got pushed to the wayside mostly for economic reasons and the field of compiler optimization was set back decades.
Fuck, forget Lisp for a moment. Just look at LuaJIT. An implementation of a high level language that will beat the pants off C or C++ in many scenarios unless the opposing developer spends a lot of effort being quite clever. Static compilation vs a tracing JIT... the speed of LuaJIT shouldn't come as any surprise but to many meme-loving fucks it somehow does.
▶ No.809532>>809535
>>809529
> We argue against call/cc as a core language feature,
Frankly that's a political matter. If you're not implementing scheme, it's nothing to whine about. And as another anon mentioned above, chances are whatever scheme implementation you're using comes with more than just undeliminated continuations anyway.
▶ No.809534>>809543 >>809546
>>809531
LuaJIT is written in C, so in the end it's just a C program beating another, poorly written one.
You are the one who is a cuck. If Lisp was truly competitive, it would show up at the top of benchmarks and would be used for scientific computing, but it doesn't because it's not and you lie!
▶ No.809535>>809543
>>809532
>he didn't read the article
>he didn't even read the introduction
Dumb Schemeposter is dumb.
▶ No.809543
>>809534
>LuaJIT is written in C, so in the end it's just a C program beating another, poorly written one.
Yeah, if you write your C code to compete with LuaJIT by actually writing a JIT compiler and putting all your application-specific logic in a DSL targeted by that JIT compiler, then you'll stand a chance of smacking down LuaJIT...
But that's not what most normal people do when they're writing a program in C, is it? No... Write a non-trivial program in C "the normal way" and then compare it to a "normal" LuaJIT implementation. The meme-lovers would have you believe that involving a high-level language in your program would make everything slower than pure C, but very often they'd be dead wrong.
>If Lisp was truly competitive, it would show up at the top of benchmarks
Who's benchmarks? Who is performing this analysis, and did they bother to even consider CL? Which CL compilers did they check? Which scheme compilers did they test, if any?
>scientific computing
By that measure, C and C++ both sucks ass and Fortran and Python are the only languages worth knowing.
>you lie!
Don't take my word for it, check out SBCL or Chez yourself.
>>809535
The article is just whining about undelimited continuations when they're hardly relevant in real world scheme programming. It's uninteresting unless you're tasked with implementing scheme yourself.
▶ No.809546>>810878
>>809534
SBCL can produce extremely tight assembly, competitive with GCC.
The main issue is that in order to achieve it the programmer typically has to provide type-declarations and other assurances to the compiler, this can make code rather ugly and isn't really in the spirit of CL.
Benchmarking sites also never go to the trouble of doing this, they just use plain code, even though in a real application it would be perfectly reasonable to optimise the performance critical parts of a programme.
I read an article a while back which illustrates this very well, including providing example disassembles.
http://blog.kingcons.io/posts/Going-Faster-with-Lisp.html
▶ No.810869>>810912 >>810940
To return to the original subject, I've found this interesting page:
https://www.dwheeler.com/essays/fixing-unix-linux-filenames.html
Basically, if you want to write real secure shell scripts, you're gonna have to use something like bash/zsh. Coreutils by themselves aren't enough, as some shell builtins like read are still vulnerable to newlines.
▶ No.810873
>>809433
Lisp was and is absolute garbage. It was Jewish poison in academia back when they were also creating feminists and antifa. They stuff it into your heads in college as it prevents you from thinking about computer problems from a computer perspective which makes you entirely ineffective. We have 60 years of hindsight on that now and it's clear from nothing of value ever being made with lisp that it had no value.
▶ No.810878
>>809546
>SBCL can produce extremely tight assembly, competitive with GCC.
Bullshit. Go to >>>808650 and prove otherwise.
▶ No.810912>>810969
>>810869
>if you want to write real secure shell scripts, you're gonna have to use something like bash/zsh
That's a funny way to spell execline.
▶ No.810940>>810969
>>810869
Error and data handling in the shell is hopeless. It's why everyone but first year CS students no longer write shellscript.
▶ No.810969
>>810912
Read the thread, maggot. I'm obviously talking about something POSIX compatible (not compliant).
Now, I'm not against something different, like this or plan9 rc, but it's gotta to be good?
Now, if only there was a simple sh/execline script comparison to get started.
>>810940
Unfortunately, the pipeline is a tool so useful and sh being a POSIX requirement makes your statement quite retarded. Sh scripts (like any script) shouldn't be used for more than "scripting", anyway.