The tale of aux.c

Re:The tale of aux.c by hossbeast on Monday September 25, 2017 @10:35PM (#15335730)

How is this specific to Linux?

[ Parent | on HN ]

Re:The tale of aux.c by drfuchs on Monday September 25, 2017 @11:11PM (#15335849)

Ok, "unix-derivative" if you prefer. FWIW, it actually happened on SunOS or maybe HP-UX, and it was before Linux existed.

[ Parent | on HN ]

Re:The tale of aux.c by flukus on Tuesday September 26, 2017 @12:42AM (#15336236)

But it could have just as easily been a windows batch file, it's not related to the OS at all.

[ Parent | on HN ]

Re:The tale of aux.c by kieranelby on Tuesday September 26, 2017 @03:16AM (#15336805)

Well, apart from the fact that UNIX-like systems have traditionally dumped core files in programs' working directories if they crash, so needing a script to clean them up.

Linux still does, though many distros set ulimit or /proc/sys/kernel/core_pattern to disable it.

[ Parent | on HN ]

Re:The tale of aux.c by SolarNet on Tuesday September 26, 2017 @04:54AM (#15337181)

Windows does this too, except it hides them in it's system folders, it even comes with a built in clean-up script you can run. Not a problem that is worse on *nix.

[ Parent | on HN ]

Re:The tale of aux.c by pjc50 on Tuesday September 26, 2017 @05:53AM (#15337378)

I'm reminded of when I discovered on a production system that "killall" is very different on Solaris to Linux.

[ Parent | on HN ]