Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1501 »

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Otto Skorzeny posted:

There's an old trick based off this where you put a file named -i in a directory to prevent yourself from accidentally rm -rfing it

I like to live dangerously, I have a file called --no-preserve-root in my root directory.

# ? Jul 21, 2012 20:02

Adbot: ADBOT LOVES YOU

# ? Apr 28, 2024 22:37

zergstain: Dec 15, 2005

Wheany posted:

I like to live dangerously, I have a file called --no-preserve-root in my root directory.

Am I wrong, or would doing that not make any difference?

Anyway, I just use echo if I'm not sure about a wildcard expansion. And I hope I never see any directory with a file called "-r" or something.

# ? Jul 21, 2012 20:28

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

zergstain posted:

Am I wrong, or would doing that not make any difference?

Hmm, I don't actually know, let me check...

# ? Jul 21, 2012 20:35

Vanadium: Jan 8, 2005

You know, if only unix used / instead of - for command-line options, then you only have to be sure that one directory, the root directory, doesn't have a file named r and this couldn't happen...

# ? Jul 21, 2012 22:09

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

If you're worried about this, the fact that it's controlled by the shell gives you an easy out: if you're using bash, you can export GLOBIGNORE=-*, and now the shell will never expand * to include something starting with dash. You could quite reasonably argue that that should be the default.

# ? Jul 21, 2012 22:45

pseudorandom name: May 6, 2007

Be advised that setting GLOBIGNORE to a non-null value will cause * to start matching .* (except . and ..), so you'll probably want to set GLOBIGNORE to -*:.*

# ? Jul 21, 2012 22:50

PrBacterio: Jul 19, 2000

But really, though, isn't that just piling workaround on workaround to get a fundamentally broken system working at that point, like this thread has so many times before (rightfully, imho) criticised, for example, PHP for? I'm not sure what the ideal solution would be, but at a guess I'd say that, at least in principle, the way Windows (and before that, DOS and CP/M) do it is the more correct one. The only reason it is so broken in Windows is (like with many things in Windows) because of layers upon layers of compatibility hacks and workarounds. But when starting from scratch I'd say a clean API for dealing with filenames and wildcard expansions that is well integrated with the APIs for opening and accessing files would be the cleanest approach. Alternatively, a clean way for applications to distinguish filename (and expanded filename) parameters from command flags might be a good solution, if the calling convention for the main program didn't just consist of a flat list of string pointers and could instead include identifyable data structures, so that an application be told, for instance, "this parameter, here, is a list of files."

EDIT: vvv Well that's okay then, I'm not delusional enough to believe we're going to get out from under the weight of the Unix legacy any time soon even in those areas where it's more of a burden than a boon (and in all fairness to Unix, that's surprisingly few), but there were some people posting earlier in this thread saying that they honestly couldn't see what's wrong with shell-base wildcard expansion vvv

PrBacterio fucked around with this message at 02:26 on Jul 22, 2012

# ? Jul 22, 2012 02:07

Opinion Haver: Apr 9, 2007

I think everybody agrees that the current system is poo poo, it's just that there's basically no way to make it not be poo poo at this point.

# ? Jul 22, 2012 02:10

Deus Rex: Mar 5, 2005

PrBacterio posted:

The reason it is a horror is because expanding arbitrary file patterns from the command line and passing them as a list of file names to an individual program can lead to unintended behaviour by that program when there are oddly-named files or no files matching a pattern. The individual application has no way of knowing whether any specific command line argument originates from a wildcard expansion of a file pattern or not and there is no one-to-one correspondence between actual command line arguments (as written by the user) and the command line parameter list (as seen by the program).
For instance, suppose you have a file that is called "--remove-files" in your directory:
code:
foo$ ls
-rw-r--r--  dumb   user         0 Jul 21 2012 --remove-files
-rw-r--r--  dbuser dbuser 7474585 Feb  2 2007 important-data.db
foo$ ls ..
drwxr-xr-x  dbuser dbuser       1 Feb  1 2007 important-data/
lrw-rw-rw-  dumb   user         0 Jul 20 2012 important-data.tar.bz -> /dev/null
foo$ tar -cjf ../important-data.tar.bz *
In this case, because there is no way for the program to distinguish between a command line option it was given on purpose by the user and something that exists only because of shell expansion, the tar command will remove the file "important-data.db" after having added it to the tar archive "../important-data.tar.bz" which is just a symlink to /dev/null; so the file is gone. This is because the actual tar program only sees the command line "tar -cjf ../important-data.tar.bz --remove-files important-data.db" with no way of knowing that the third and fourth arguments originated from a wildcard expansion and should be treated as file names. This is a contrived example, of course, but I think you can see where I am going with this. Arbitrarily manipulating the strings given as command line arguments to individual applications to deal with file name patterns is an ugly hack that should never have seen the light of day, imho.

(EDIT: fixed typos,added clarification)

isn't this what -- is for? It signals to stop parsing options after that point.

code:

tom@localhost:~/tmp/foo$ ls
bar  baz  foo  --remove-files
tom@localhost:~/tmp/foo$ tar -cjf ../important-data.tar.bz -- *
tom@localhost:~/tmp/foo$ ls
bar  baz  foo  --remove-files
tom@localhost:~/tmp/foo$ ls ../important-data.tar.bz 
../important-data.tar.bz
tom@localhost:~/tmp/foo$

# ? Jul 22, 2012 04:10

Jonnty: Aug 2, 2007; The enemy has become a flaming star!

Has anyone actually experienced this being a problem ever? I agree it's a bit of a horror, but it just seems like the least-impact horror I've ever seen. The bigger horror is probably naming a file after a command line option in the first place...

# ? Jul 22, 2012 04:16

UraniumAnchor: May 21, 2006; Not a walrus.

It's entirely possible to have it happen by accident and it's not immediately obvious how to properly fix it without blowing everything up.

# ? Jul 22, 2012 08:29

My name aint Jerry: Sep 4, 2011; Good job with notjerry.org, Not Jerry. Here is not-a-trophy for you.

I fail to see how it is different than any other user input sanitization issue, and that you should blame the shell, and not the user who blindly accept any kind of filenames without checking.

# ? Jul 22, 2012 09:15

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

PrBacterio posted:

But really, though, isn't that just piling workaround on workaround to get a fundamentally broken system working at that point, like this thread has so many times before (rightfully, imho) criticised, for example, PHP for?

Well yes, I suppose, but the shell's purpose is to call out to programs that are free to do their own thing. PHP on the other hand pisses people off so much because its problems involve things that are under its own control.

# ? Jul 22, 2012 09:17

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Gazpacho posted:

Well yes, I suppose, but the shell's purpose is to call out to programs that are free to do their own thing. PHP on the other hand is a closed system and pisses people off so much because its problems involve things that are under its own control.

The issue here is that the way the shell calls out to programs that do their thing is the broken part. It's just that shell expansion and quoting rules are extremely hard to understand and misleading (you think bash quoting worked like it does in other languages? Hah.), and it's impossible for a program to tell whether an argument was explicitly specified or not.

Any system that automatically builds a shell command line instead of an argv array to pass to execvp is usually going to be exploitable.

# ? Jul 22, 2012 09:22

xf86enodev: Mar 27, 2010; dis catte!

This whole debate is loving pointless. Shell expansion is well defined and if you fail to read the docs or abuse your tools you're the only one to blame.

You wouldn't call a hammer a horror because you keep hitting yourself everytime you try to use it. Well, you probably would.

eta: ^^^ bash is poo poo though, don't use it. It's the hippie guitar version of a hammer.

xf86enodev fucked around with this message at 09:37 on Jul 22, 2012

# ? Jul 22, 2012 09:33

shrughes: Oct 11, 2008; (call/cc call/cc)

xf86enodev posted:

This whole debate is loving pointless. Shell expansion is well defined and if you fail to read the docs or abuse your tools you're the only one to blame.

That's a completely retarded worldview if your goal is for software to work correctly or the shell to be used correctly.

Your goal must be to have people memorize arcana and blame people whose planes crash because they flipped the wrong lever instead of blaming the people who made the cockpit design confusing. Which is what cockpit designers don't do, they blame the cockpit design when humans use them incorrectly, you don't glorify surprises in interface design and blame the user unless your goal is to just blame people.

# ? Jul 22, 2012 09:38

Vanadium: Jan 8, 2005

Maybe shell glob expansion should just insert a -- before it first applies. :shobon:

# ? Jul 22, 2012 09:55

xf86enodev: Mar 27, 2010; dis catte!

shrughes posted:

That's a completely retarded worldview if your goal is for software to work correctly or the shell to be used correctly.

Your goal must be to have people memorize arcana and blame people whose planes crash because they flipped the wrong lever instead of blaming the people who made the cockpit design confusing. Which is what cockpit designers don't do, they blame the cockpit design when humans use them incorrectly, you don't glorify surprises in interface design and blame the user unless your goal is to just blame people.

"You want me to memorize all those levers and switches? Wtf!? I can't hook up my 360 controller?"

You can't be serious.

eta real CLI horror:

code:

rm -rf / home/butts/angry-emails

Although I think modern systems warn you.

e2: And that's the thing. You can't design a system that's proof to human error. You can built-in safe-guards but you'll never get 100% safe.

In the meantime you train people to know where their weaknesses are and where the systems have their pitfalls.

xf86enodev fucked around with this message at 14:00 on Jul 22, 2012

# ? Jul 22, 2012 13:39

Zombywuf: Mar 29, 2008

shrughes posted:

Your goal must be to have people memorize arcana and blame people whose planes crash because they flipped the wrong lever instead of blaming the people who made the cockpit design confusing. Which is what cockpit designers don't do, they blame the cockpit design when humans use them incorrectly, you don't glorify surprises in interface design and blame the user unless your goal is to just blame people.

Cockpit design has more complicated issues than that. Mainly that certain interfaces are standardised and it's what pilots are trained on. If you make a new interface you have to work through so many layers of international bureaucracy that it's deemed not worth the effort.

# ? Jul 22, 2012 14:55

Janitor Prime: Jan 22, 2004; PC LOAD LETTER

What da fuck does that mean; Fun Shoe

xf86enodev posted:

In the meantime you train people to know where their weaknesses are and where the systems have their pitfalls.

Please point me to a an instruction manual for Bash that shows these common pitfalls, this is the first I'm hearing of it.

# ? Jul 22, 2012 16:04

Jonnty: Aug 2, 2007; The enemy has become a flaming star!

would quoting every argument individually (and then escaping any quotes within the filename) work??? Or would that just eventually lead to mysql_escape_string_no_really_i_mean_it_this_time() style horrors?

# ? Jul 22, 2012 20:24

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Jonnty posted:

would quoting every argument individually (and then escaping any quotes within the filename) work??? Or would that just eventually lead to mysql_escape_string_no_really_i_mean_it_this_time() style horrors?

I don't understand what you mean.

# ? Jul 22, 2012 21:16

fritz: Jul 26, 2003

Jonnty posted:

The bigger horror is probably naming a file after a command line option in the first place...

I've certainly done that by accident, and I know a lot of other people who have too.

# ? Jul 22, 2012 21:18

Jonnty: Aug 2, 2007; The enemy has become a flaming star!

Suspicious Dish posted:

I don't understand what you mean.

I don't understand what quotes do in bash, ignore me

# ? Jul 22, 2012 21:27

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

MEAT TREAT posted:

Please point me to a an instruction manual for Bash that shows these common pitfalls, this is the first I'm hearing of it.

Didn't you see his post? You shouldn't even be using Bash (the most popular default shell that most new users are going to be exposed to and therefore learn) because it's terrible!

Scaramouche posted:

Don't know if this is laugh, cry, or just a disappointed, despairing sigh:
http://www.theregister.co.uk/2012/07/20/big_boobs_in_linux/

Both the news and the tone of the article are worth a depressing sigh. Or maybe I'm misreading the Register's semi-typical lack of professionalism.

# ? Jul 23, 2012 15:29

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

http://cwe.mitre.org/top25/index.html

OS injection is the number 2 vulnerability. Programs should not be spawning the shell, nor calling system. It's a poor choice of APIs that the correct way to do it both requires a fork and exec, and that we don't have a simple spawn API that takes an argv and double forks.

# ? Jul 23, 2012 17:05

ToxicFrog: Apr 26, 2008

Suspicious Dish posted:

http://cwe.mitre.org/top25/index.html

In the year 2012, buffer overruns are still #3 on that list. :negative:

# ? Jul 23, 2012 17:32

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

ToxicFrog posted:

In the year 2012, buffer overruns are still #3 on that list.

I blame it on the C standard library. sprintf is in there, but asprintf is not.

# ? Jul 23, 2012 17:34

Zamujasa: Oct 27, 2010; Bread Liar

New project from Boss! It involves raw sockets in PHP.

So of course I open it up and hang on, this isn't boss's style at all. I mean, it has comments. And not just the "//lineofcode()" kind, either, but actual comments!

code:

/* Allow the script to hang around waiting for connections. */
set_time_limit(0);

/* Turn on implicit output flushing so we see what we're getting
 * as it comes in. */
ob_implicit_flush();

Well, three seconds and one depressing :google:

later, surprise.

The code is incredibly hacked up, but it's funny that it still works. Case in point, you can leave a dangling string out and PHP does not give a gently caress:

code:

//    $msg = "\nWelcome to the PHP Test Server. \n" .
        "To quit, type 'quit'. To shut down the server type 'shutdown'.\n";
//    socket_write($msgsock, $msg, strlen($msg));

Reminds me of my last job where I'd see code that was literally just "1;", as if it did something.

The rest of the code is similarly hacked up, with a lot of randomly commented things, magic numbers, and all sorts of other good things.

Today is going to be a long day.

# ? Jul 23, 2012 19:03

tef: May 30, 2004; -> some l-system crap ->

Zamujasa posted:

Reminds me of my last job where I'd see code that was literally just "1;", as if it did something.

It does something in perl:
http://stackoverflow.com/questions/5293246/why-the-1-at-the-end-of-each-perl-package

# ? Jul 23, 2012 19:10

het: Nov 14, 2002; A dark black past
is my most valued
possession

Zamujasa posted:

Case in point, you can leave a dangling string out and PHP does not give a gently caress:
code:
//    $msg = "\nWelcome to the PHP Test Server. \n" .
        "To quit, type 'quit'. To shut down the server type 'shutdown'.\n";
//    socket_write($msgsock, $msg, strlen($msg));

You can do that in perl, ruby, and python too btw.

# ? Jul 23, 2012 19:30

Zamujasa: Oct 27, 2010; Bread Liar

het posted:

You can do that in perl, ruby, and python too btw.

I figured. (Probably in a lot of other languages.)
But in the case of PHP, I think it just describes how sloppy he (and others) can be.

There are a lot of other horrors in this code (like replacing binary data with boss's favorite ASCII markers, then switching back, because that data will "never occur"), though.

# ? Jul 23, 2012 19:36

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

Suspicious Dish posted:

I blame it on the C standard library. sprintf is in there, but asprintf is not.

Having worked on a platform with spectacular facilities for dynamic allocation and management, I can assure you that the real problem is programmers just not knowing what memory is.

I guess it counts as a horror that on this platform, a problem I had to clean up again and again was local string buffers sized according to the maximum filename length, which had nothing to do with filenames. And this at more than one company, it wasn't an issue with a particular programmer.

Gazpacho fucked around with this message at 20:43 on Jul 23, 2012

# ? Jul 23, 2012 20:35

Zombywuf: Mar 29, 2008

het posted:

You can do that in perl, ruby, and python too btw.

Pretty sure you can do it it C.

# ? Jul 23, 2012 20:36

Civil Twilight: Apr 2, 2011

Zombywuf posted:

Pretty sure you can do it it C.

You can; gcc and clang will point it out as a warning, but it works just fine.

# ? Jul 23, 2012 20:42

Zhentar: Sep 28, 2003; Brilliant Master Genius

Gazpacho posted:

I can assure you that the real problem is programmers just not knowing what memory is.

Every time I hear "Out Of Memory crash? But my machine has plenty of RAM!", I die a little on the inside :smith:

# ? Jul 23, 2012 20:49

Johnny Cache Hit: Oct 17, 2011

I'm going to bump shellchat while it's on this page.

I've always used bash, probably because it's been Debian's default for a while. But if it sucks, what shell should I be using instead?

# ? Jul 24, 2012 12:13

Mustach: Mar 2, 2003; In this long line, there's been some real strange genes. You've got 'em all, with some extras thrown in.

I use rc (among other things) from plan9port.

# ? Jul 24, 2012 16:13

Doctor w-rw-rw-: Jun 24, 2008

Kim Jong III posted:

I'm going to bump shellchat while it's on this page.

I've always used bash, probably because it's been Debian's default for a while. But if it sucks, what shell should I be using instead?

I use zsh. It's pretty nice. What's so bad about bash?

# ? Jul 24, 2012 17:24

Adbot: ADBOT LOVES YOU

# ? Apr 28, 2024 22:37

geonetix: Mar 6, 2011

Kim Jong III posted:

I'm going to bump shellchat while it's on this page.

I've always used bash, probably because it's been Debian's default for a while. But if it sucks, what shell should I be using instead?

I use zsh on most of my machines, unless it's not available. In that case I tend to use tcsh, ksh or csh (in that order or preference).

I'm not actually sure why, it's probably because I learned to computer that way. And I cannot live without "bindkey -v" to enable vi-like editing. If somebody has an actual valid pro/cons table of zsh vs bash vs (t)csh I'll be the first to read it.

# ? Jul 24, 2012 19:49

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1501 »