/tech/ - Technology★

>Currently in shell everything is a string and it breaks everything.

how many servers are you responsible for?

>>921122

two

what shell?

You're complaining about fundamental Unix limitations, not about the shell. Good luck fixing that without throwing out everything.

You're too retarded to see the real problem. What would fix POSIX would be to standardize a simple format for tabular and tree data. For tabular, simply use RS and FS variables (also, forbid ASCII FS..US in filenames), for trees, I don't know what would be best, but something even simpler than JSON would be appreciable.

UNIX can't be fixed. UNIX has the same problems it had in the 70s and 1991 except now the shills are better at tricking users into not realizing they are problems.

Date: Fri, 1 Mar 91 14:27:50 -0800
Subject: A Joke In Every Sentence

In a fit of work avoidance, I just flipped open a copy of
The Sun Observer, and read the following from a ``helpful
hints'' type column.  It is NOT A JOKE.

  Using noclobber and read only files only protects you
  from a few occasional mistakes.  A potentially
  catastrophic error is typing

    rm * .o

  instead of

    rm *.o

  In the blink of an eye, all of your files would be gone.
  A simple yet effective preventive measure is to create a
  file called -i in the directory in which you want extra
  protection:

    touch ./-i

  In the above case, the * is expanded to match all of the
  filenames in the directory.  Because the file -i is
  alphabetically listed before any file except those that
  start with the character: !#$ percent&`()*+,.  The rm
  command sees the -i file as an argument.  When rm is
  executed with the -i argument, files will not be deleted
  unless you verify the action.

  This still isn't perfect.  If you have a file that starts
  with a comma in the directory, it will come before the
  file starting with a dash and rm will not get the -i
  argument.  SunOS's make utility creates file starting
  with a comma if the make file understands hidden
  dependencies by having the following line in the make
  file:

    .KEEP-STATE:

  The -i file also won't save you from errors like

    rm [a-z]* .o

The bit about files that appear before -i is garbled in the
original.  I blame nroff.

>>921167

>advocating handholding unrionically

Go use Windows, faggot. Your retarded quote made by a retard doesn't even relate to the thread. Also, nobody wants to discuss with an autist confusin philosophy and implementation (inb4 not handling errors and all this bullshit are part of the philosophy, they're not).

>>921196

>Windows 10

>not Windows Server 2016

You are a superpleb.

There is only one flaw in Unix shells.

zfs destroy or zpool destroy.

Pretty easy to fix though, just write a wrapper that provides verification for the destroy command.

>>921249

>There is only one flaw in Unix shells.

>zfs destroy or zpool destroy.

How is this related to sh?

>>921182

True Unix has never been tried.

>can't even safely do echo "$a" without it fucking up for some values of $a

UNIX was a mistake.

>ITT: linux is bash

>ITT: unix is bash

>ITT: *nix is bash

You guys do know other shells exist, right?

>>921283

Is bash the only shell that has these problems?

>>921167

That's pretty clever failsafe for important dirs.

I wouldn't call it an issue, who names their files with a starting - anyway?

>>921303

who names their files starting with a . ... oh wait like half my home directory.

>clever

Watch as I transform a bug into a feature.

>>921310

Who doesn't pay attention to what they're about to do before hitting Enter on an "rm" command?

Oh wait retards.

>>921303

see OP pic

>>921318

>implying it's only rm

>>921321

Does your editor warn you when you try to exit without saving?

>>921158

Shell is a thin wrapper around fork and exec. Exec/c don't have this problem, args wil be passed to the process unsplit.

>>921283

There are certain requirements for something to be a POSIX shell. Same goes for unix. Unquoted vars being split on $IFS is one of those things

>>921323

Not him, but vim wont let you :quit an unsaved buffer. You can still ZQ or :q! without trouble though.

>>921373

Passing unsplit strings to a process is doable even in bourne sh, if unnecessarily tedious.

Telling the process which arguments are flags and which ones aren't (the topic of this thread) is impossible to do consistently. Not all software supports the -- separator.

sudo apt-get install -y powershell

Or, like, use Python.

>>921196

>open source a bad thing

>implying all linux users use a shit unstable distro like arch

>amd drivers literally preform better on linux

>implying winshit's init is better than systemd and implying we're forced to use it

>minimal googling

>googling

jesus you're retarded

the virgin linux loser

-must have autistic colors for the few cli programs he uses

-complains when distros dont add user to sudoers by default

-thinks i3 + vim makes him look cool

-would use a systemd distro if it wasn't uncool

-unironically compiles everything from source

-bloated core components

-doesn't care about his package manager as long as it has dependency resolution

THE CHAD BSD BEASTIE

-has disabled colors from appearing on his system

-runs everything as root. fears nothing

-"yeah, i'd use dwm if it weren't so bloated"

-doesn't have to worry about an init being sane, they all are

-thanks god each day for binary package management

-minimal, fast core components. starts an hour long rant in irc when his system doesn't boot in less than 3 seconds

-urges devs to make a back-end package manager with no dependency resolution and to make it the default package manager

>>921120 (OP)

> Can we please talk about how UN*X shell is still not fixed in 2018?

Yes, it is, and that's by design. Being able to write shell scripts is just a convenience for gluing simple things together. If you need a more powerful scripting system then use a proper scripting language:

#!/usr/local/bin/guile -s
!#

(system* "touch" "look ma, spaces.txt")

From the documentation:

- Scheme Procedure: system* .  args
     Execute the command indicated by ARGS.  The first element must be a
     string indicating the command to be executed, and the remaining
     items must be strings representing each of the arguments to that
     command.

     This function returns the exit status of the command as provided by
     `waitpid'.  This value can be handled with `status:exit-val' and
     the related functions.

     `system*' is similar to `system', but accepts only one string
     per-argument, and performs no shell interpretation.  The command is
     executed using fork and execlp.  Accordingly this function may be
     safer than `system' in situations where shell interpretation is not
     required.

     Example: (system* "echo" "foo" "bar")

>>921542

BTW, system* will also not carry out shell expansion, so

(system* "rm" "*")

Will actually try to delete the file named '*' and if it doesn't exists it will throw an error:

scheme@(guile-user)> (system* "rm" "*")
rm: *: No such file or directory
$1 = 256

You can use 'system' (without the asterisk at the end) if you really want to expand wildcards. It's all about choosing the right tool for the job.

>>921542

That's not the problem this thread complains about. Try:

#!/usr/local/bin/guile -s
!#
(system* "touch" "-foo")

This problem lies deeper than the shell.

>>921542

(Not to mention that sh has no trouble with 'touch "look ma, spaces.txt"' so you haven't demonstrated anything sh can't trivially do, even though guile offers plenty)

>>921552

You have to fight the shell to get what Guile (or any other scripting language) gives you for free. Yes, you could put quotation marks around the file name, but what if instead of a fixed file name you splice in the output of another command? As shell scripts grow more complex you have to write them more defensively. I use a linter, so I find most of the obscure details before the code even runs, but just look at all this shit (the rules SCxxxx):

https://github.com/koalaman/shellcheck/wiki

>>921432

Only the shell have to support it and bash do it in the right way.

>>921569

No.

Run "touch -foo". Notice that it doesn't create a file named -foo. You have to use "touch -- -foo".

Now install jpegoptim and make a JPG file called -foo.jpg. Run "jpegoptim -foo.jpg" and "jpegoptim -- -foo.jpg". Notice that neither work.

>>921575

jpegoptim "-foo.jpg"

>>921592

You don't understand how shells work.

Quotes are for the shell's convenience. They don't get passed to the process,

>>921602

okay, but does it work

>>921603

No.

If you want to gain an understanding of what processes can and can't see, play around with passing arguments to this Python script:

#!/usr/bin/env python3
import sys
print(sys.argv)

It's very simple, if unexpected to beginners.

>ITT: Why can't I name my file "sudo rm -rf /" UNIX is shit!

>>921542

So lisp has a list data type and that lets you work with spaces correctly

but you still have the problem of paths whose name starts with -. Since it to shell itself they're all just strings.

You'd need to go deeper to fix this. it can't be repaired just by making a better way to call system.

>>921633

>>921551

Yeah, you're right. I was mostly looking at the OP pic and how it's a non-issue when using a scripting language. The only real solution for this is to forget about the shell and use system calls through a scripting language's FFI.

>>921120 (OP)

>complaining about spaces

Try single quotes or percent signs.

>>921120 (OP)

How fucking hard Is it to add quotes, you fucking mong?

>>921633

>You'd need to go deeper to fix this.

int execv(const char *path, char *const argv[]);

Look at that shit.

>>921656

A solution is to specify a new ENV-based protocol. Let executables signal that they support it, in which case options can be passed in through environment variables prefixed with OPT.

It's a gigantic hack, but it gives you proper key-value pairs.

>>921120 (OP)

God I hate you "Unix" fuckheads. Unix was a proprietary system 50 years ago, no sane person is using it anymore.

>>921283

Bash is the shell of the GNU operating system.

>>921676

Unix is also a rough standard that's used as the basis of a distressingly large share of widely used operating systems.

Which name would you use for this occasion?

>>921678

unix-like

>>921167

Just alias rm as rm -i

>>921676

>Unix was a proprietary system 50 years ago, no sane person is using it anymore.

Mac OS X users are often obnoxious, but I've never had any reason to question their sanity.

https://www.opengroup.org/openbrand/register/

>>921120 (OP)

UN*X shell is unfixable nigger. adding two types isn't gonna fix shit (will it will fix 1/10000000 problems)

>>921676

Every OS that exists right now is basically the same bullshit as UNIX, nigger.

>>921660

see OP pic

>>921740

TempleOS

RiscOS

FreeDOS

Everything in UNIX was fixed by Plan 9. Try out it's shell, rc, it truly is better than the inferior UNIX sh.

>>922111

Does rc solve the particular problem expressed in this thread's OP's text?

>>921122

How many are YOU responsible for?

>>so completely different group of people had to come with xorg, then another completely different group with wayland

BSD has won by attribution

>>921797

In this scenario, you're like a feminist screaming about how you should be allowed to shit in your husband's cereal and piss on his sheets and acts surprised when he reacts appropriately.

>>921630

>Let's not dislike bad things

>>921677

And GNU is Not Unix.

>>921373

>Not him

The question was for him.

Obviously every single other piece of software guards against loss of user work because the assumption is user work is valuable. Unix-like don't because the user work is assumed to be worthless and temporary or backed up on a fucking external tape.

It's a server OS the ~1.0% desktop usage speaks volumes.

>>922203

>the user work is assumed to be worthless

No its because normie OS tools are for retards the lowest common denominator. The trash can (so you can restore), the auto save (because they don't know how to save), the icloud (because they would rather apple store there shit than have to deal with backups themselves).

>>922244

Saving at all is for normies with shit-tier memories.

>>922111

>Everything in UNIX was fixed by Plan 9.

That would make Plan 9 a clone of Multics, but it's not. It doesn't use segmentation, it still has null-terminated strings, the commands are mostly ports of UNIX commands, it's still written in C, it still has broken fixed-length buffers, and dynamic linking was removed instead of fixed.

>>922134

No, it just made the documentation worse so you have to look at the source code to figure anything out. AT&T shills learned in the 80s that bad documentation and bad code can force programmers to learn C in order to understand and fix the OS, which is why so many C weenies appeared even though everyone knew C sucks.

>>922203

>Unix-like don't because the user work is assumed to be worthless and temporary or backed up on a fucking external tape.

"The user work is assumed to be worthless and temporary" is true, but backups are assumed to be worthless and temporary too.

>It's a server OS the ~1.0% desktop usage speaks volumes.

It sucks at servers even more, but companies can afford to hire a permanent weenie and buy more expensive hardware that can handle the wasted cycles and slow UNIX I/O.

Date: Fri 12 Apr 91 13:27:28-PDT
Subject: Re: Un*x Is The Pits ...


    Stanford had a system called "labrea".  It was (is?) a
vax 750 with 10 fuji eagles (4.5 Gbytes, which was a lot
when it was first around...)

    Tape handling has always been a real weak point of unix.
Any real operating system has much better backup/restore
capabilities, and a lot of these are 10s of years old...

	From: BW
	OK... /home/gn is back on-line and ready for use. 

        There were several read errors on the old disk
        while the files were being transferred, and it's
        impossible to tell exactly which files were
        affected...  If anyone finds any trashed or
        incomplete files, let me know and I'll try to
        retreive them from backup tapes.

Doesn't it give you that warm, confident feeling to know
that things aren't Quite Right, but that you'll have to wait
'til you need something to know Just What?  Life on the
Edge.

Get with the program -- remember -- 90% is good enough.  If
it's good enough for Ritchie, it's good enough for me!

>nooo don't improve unix!~ keep it crap forever

why though?

>>922203

Normalfags have no business using a shell just like they have no business playing around in a construction site. Powerful tools are dangerous.

>>921575

jpegoptim ./-foo.jpg

>>921318

>not being spastic as fuck and accidentally pressing keys all over

I live to suffer.

>>922361

That works. But what if you're writing a script, and don't have fine control over the filenames? You can't blindly prepend ./, it doesn't work for absolute filenames. So now you have to check the first character of each filename, which is mildly annoying in bash and an absolute pain in bourne sh.

And that's without getting into tools that take arbitrary string arguments that don't represent filenames, and so don't support that workaround.

Unix is terrible around the edges. Central cases are nice and simple, edge cases are impossible to deal with consistently, if at all.

>>922367

> That works. But what if you're writing a script, and don't have fine control over the filenames? You can't blindly prepend ./, it doesn't work for absolute filenames. So now you have to check the first character of each filename, which is mildly annoying in bash and an absolute pain in bourne sh.

You can do

jpegoptim `pwd`/-foo.jpg

>>922372

No, you can't. Let's say the filename is inside $fname, and we're in /home/user. The `pwd`/$fname for /tmp/foo.jpg becomes /home/user//tmp/foo.jpg, which is wrong.

Another problem is that you didn't quote it, so if there are spaces in the directory path it breaks.

>>922367

then use find

>>922377

I'm thinking of a case in which the filename was passed in by the user of the script and there's no other reason to mangle it.

>>922340

>reeee hard hats are for normies

woah you are so cool

>>922399

Hard hats don't really get in the way at all. Real coal miners don't wear respirators because they are a PITA.

>>922418

What's the analogy even mean? Making it so that mv, cp and rm don't assume your data is easily replaced is nowhere near adding some terrible user burden. Nor is fixing retarded bugs.

>>922480

when confronted with logical refutations these people just sperg out with false analogies instead of ever conceding defeat.

>>922375

>>922372

>>922367

>>922361

>>921575

THIS is why you need a "path" data type, separate from the "flag" data type.

>>922480

>RM should not actually delete files without asking

Why the fuck am I typing RM then

>>922509

inb4 *rm

>>922399

What the fuck do you even want? If you want your hand held through basic file operations then use a desktop's UI. If you want to do low level operations that are often unsafe use a shell.

>>921120 (OP)

Can't you just use quotes?

>rm this image.jpg

>no such file or directory

<rm "this image.jpg"

Unix filenames are pretty bad, in some cases they're even executable. The alternative is breaking compatibility and convenience though so just be less shit. A single find command can fix all your bullshit filenames on your whole system at once.

>>921120 (OP)

>Currently in shell everything is a string

I know right OP?

If only they were using a binary format with well defined boundaries, like a null characters. But maybe systemd could be managing a shell too, that will fix the problem!

>>922539

quotes help but do not completely resolve the issue.

having separate data types for paths, flags and strings would fix it 100%.

>>922582

nul separated chars is actually a very very good way to work. I learned it from uriels non-harmful list (STOMP).

>using spaces in filenames

That Bitch deserved it.

>>921511

>superior NVIDIA product

>>>/telaviv/

>>>/bog/

>>>/facebook/

>>927042

Actually, between Intel, AMD, ARM, IBM, and Nvidia, Nvidia is the ONLY one without an R&D Center in Israel, that makes Nvidia the least Jewish of them all

void
options() {
  fprintf(stderr, "{\"flags\": {"
    "\"--help:-h\": [\"void\", \"Shows help text\"],"
    "\"--version:-v\": [\"void\", \"Shows version\"],"
    "\"--depth\": [\"int\", 0, 100, 20, \"Recursion limit\"],"
  "},\"args\": ["
    "[\"file\", \"path\", \"File to read\"],"
    "[\"report?\" \"path?\", \"Output file to write a report to\"],"
  "]}");
}
//...
int
main(int argc, char **argv) {
//..
  if (option == "--OPTIONS") {
    options();
    return 0;
  }
//...
}

The shell will then automatically attempt to call --OPTIONS on programs and try to get valid JSON, and then validate the arguments. Of course this is still a hack to duct tape UNIX, but it's better than nothing. Now you can have the shell understand flags, paths and value types.

>>927043

True jews don't make it obvious they're jews.

>>921120 (OP)

>this shilling against the only OS model that isn't controlled by a single company

What a (((coincidence))).

>>921120 (OP)

you need to just get used to the unix way

>>927046

That's not safe. There are programs that don't take options at all, and would interpret a single --OPTIONS in their argv as an output file and happily start doing things they shouldn't be doing. It needs to be possible to determine without running the program.

>>927279

presumably the shell wouldn't pass --OPTIONS to the program

>>927316

That's what >>927046 said:

>call --OPTIONS on programs

This is fundamentally broken.

How about OP use his point-and-click GUI instead?

>>922832

>implying that faggot reads obscure mongolian nail art forums