Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

fork() can fail

rachelbythebay.com

Post reply on HN
Print view View original

261–270 of 320 posts

Re: fork() can fail

#261

Post by mnw21cam »

dllthomas wrote: post #80
ygra wrote: post #76

Earlier quoted context omitted.

Which probably can be summarized as »global state is a really bad idea«.

I wonder if it would be worthwhile to forego the notion of a CWD for processes entirely.

CWD is a useful concept. If I run gimp in a particular directory, I'd like it to show that directory in the file dialogue when I try to load or save an image.

What is evil is a program changing its working directory. That's when it becomes an evil global variable, rather than a non-evil global constant.

Re: fork() can fail

#262

Post by mst »

hollerith wrote: post #214
swah wrote: post #29

Earlier quoted context omitted.

In those times I wish I could use the emacs lisp way: (let (dir "/foo") (create-directory dir) (with-current-directory dir (delete-all-files-recursively))) Factor recognized the value of dynamically scoped variables: http://concatenative.org/wiki/view/Factor/FAQ/What's%20Facto... A lot of code became much simpler because of that decision.

I fail to see how dynamic scope pertains to the code you wrote or helps avoid the bug described in grandparent. Specifically, the code you wrote would behave the same if `dir` had lexical scope.

The with-current-directory part is the dynamic part - i.e. within its dynamic scope, the current directory is now dir.

The scoping of the dir variable itself is irrelevant.

Re: fork() can fail

#263

Post by mnw21cam »

japaget wrote: post #3

See also https://news.ycombinator.com/item?id=8189968 for another UNIX trap for the unwary.

I sometimes drop a "--help" or "--version" file in a directory I don't want to accidentally run "rm *" in.

Re: fork() can fail

#264

Post by samspot »

klodolph wrote: post #74
samspot wrote: post #72

Earlier quoted context omitted.

Annoyingly, that article refers to the One True Brace Style but doesn't bother to define it or link to it!

The "One True Brace Style" is actually a specific style with that name. It is based on the K&R style, with the additional stipulation that all `if`, `else`, `for`, and `while` statements use braces.

Thanks. I googled and found a page saying OTBS was different from K&R, which was pretty confusing!

Re: fork() can fail

#265

Post by xxs »

jacquesm wrote: post #255
xxs wrote: post #232

Earlier quoted context omitted.

The OP said: wrap in a macro having similar properties (ala pseudo code).

Good luck writing a macro in C to express language functionality for which you don't have the primitives. It's not exactly lisp. Think of C macros as a way to save you some typing and lisp macros as a way to extend the language.

you can definitely save the chdir and restore it macro.

Re: fork() can fail

#266

Post by hollerith »

mst wrote: post #262
hollerith wrote: post #214

Earlier quoted context omitted.

I fail to see how dynamic scope pertains to the code you wrote or helps avoid the bug described in grandparent. Specifically, the code you wrote would behave the same if `dir` had lexical scope.

The with-current-directory part is the dynamic part - i.e. within its dynamic scope, the current directory is now dir. The scoping of the dir variable itself is irrelevant.

`with-current-directory` has to be a macro because if it is not, then the evaluation of (delete-all-files-recursively) happens before the definition of with-current-directory can change the current directory.

What the person meant when he wrote, "In those times I wish I could use the emacs lisp way," is, "In those times I wish I could use a lisp _macro_" -- particularly, one of those macros that makes a change, runs some code ("the body") then undoes the change.

Since all lisps have macros, the code above would work in any lisp -- not just Emacs Lisp. Among lisps, Emacs Lisp is famous for its dynamically scoped variables. Consequently, the specific reference to Emacs Lisp perpetuates the confusion that how variables are scoped has anything to do with what we have been talking about.

Re: fork() can fail

#267

Post by hadoukenio »

kabdib wrote: post #209

When I was young and really didn't understand Unix, my friend and were summer students at NBS (now NIST), and one fine afternoon we wondered what would happen if you ran fork() forever. We didn't know, so we wrote the program and ran it. This was on a PDP-11/45 running v6 or v7 Unix. The printing console (some DECWriter 133 something or other) started burping and spewing stuff about fork failing and other bad things,…

That was a cool story. I wanted to know more so I looked at your profile.

Oh, it's you. That story makes you even more awesome :)

Re: fork() can fail

#268

Post by acdha »

donatj wrote: post #166
knocte wrote: post #139

Earlier quoted context omitted.

Are you sure? And what if $programmer forgets to check what's in err? What would pid contain in that case? I mention this because I guess you quoted a kind of syntax that matches the one from Go. So then I'm guessing that Go would simply ignore the error in this case. However, having a proper exception mechanism, if you don't catch the problem, then it bubbles up, and the program doesn't continue with wrong data (whi…

Actually if you want to not handle an error, you have to do either _ = err or just go data, _ = doStuff(), both of which are very visible. You can basically scan your codebase for _'s and find all the unhanded exceptions. If you don't do something with a variable, eg I do myInt := 1 but I don't use myInt go simply refuses to compile.

Technically true but most of the [admittededly modest] Go code I've seen had that error punt all over the place. I really wish they'd learned from C and either banned assigning _ for errors or threw a compiler error if the next line wasn't a _ check.

On second thought, it'd probably avoid some nasty production failures if that behaviour was true for everything which can return an error.

Re: fork() can fail

#269

Post by acdha »

tracker1 wrote: post #204
Mister_Snuggles wrote: post #170

This reminds me of the time I was telnet'd (since SSH wasn't a thing at the time) into a remote SunOS/Solaris server. At the time my only Unix experience was with Linux. "killall -9 httpd" gave an unhelpful error message. "killall httpd" also gave an unhelpful error message. "killall", which would give you usage instructions in Linux, killed all processes on the system. Reading this article makes me figure that killa…

That's funny... I almost always try "command --help" first if I'm not sure. Of course some may point out "man command" but I always find man painful, and revert to google.

At least one hairy old Unix killall took no arguments – so "killall --help" was just as bad…

Re: fork() can fail

#270

Post by tedunangst »

jacquesm wrote: post #255
xxs wrote: post #232

Earlier quoted context omitted.

The OP said: wrap in a macro having similar properties (ala pseudo code).

Good luck writing a macro in C to express language functionality for which you don't have the primitives. It's not exactly lisp. Think of C macros as a way to save you some typing and lisp macros as a way to extend the language.

setjmp and longjmp are sufficient building blocks for this.
Post reply on HN