On Tue, Dec 19, 2006 at 02:22:40PM -0800, jrod...@hate.spamportal.net wrote:
> 2) Create the file write-only, and cross your fingers.
Duh. I really meant read-only here. Of course the steps really are
something like:
- open the nonexistent file, read-write.
- call chmod to change the permissio
On Tue, Dec 19, 2006 at 09:53:56AM +0200, Yossi Kreinin wrote:
> Yeah, that's better - no need to terminate processes! Fuck those
> processes. They think they can use my files, ha! But no, I won't
> *terminate* them. That punishment is too light. I will remove the
> files they are using and then
So, in ISO 8601 and RFC 2822, positive time zone offsets denote zones east
(ahead) of Greenwich, but the POSIX TZ environment variable uses the
opposite sign. STUPID!
Surely US time zones cannot be LESS and therefore INFERIOR by having
NEGATIVE offsets???!!!
Tony.
--
There is this special bi
So, in ISO 8601 and RFC 2822, positive time zone offsets denote zones east
(ahead) of Greenwich, but the POSIX TZ environment variable uses the
opposite sign. STUPID!
Tony.
--
f.a.n.finchhttp://dotat.at/
SOLE: EAST VEERING SOUTHEAST 3 INCREASING 4 OR 5. MODERATE. FAIR. GOOD.
On Tue, Dec 19, 2006 at 01:27:40PM +, Earle Martin wrote:
> On 19/12/06, Jarkko Hietaniemi wrote:
> >You hate them until your code needs to work in medieval environments.
>
> Shell scripts: setting castles on fire and shooting people in the
> throat with arrows since 1284.
Yeah, and bloody t
> Why-oh-why are vile constructs like ${1+"$@"} still being used?
$@ is so hateful I don't see why they bothered trying to make it even
minutely less so without actually fixing it.
$ set a b c
$ echo "build/$...@.c"
build/a b c.c
In what circumstance is that *ever* desirable? At least when you n
On 12/19/06, Yossi Kreinin wrote:
During the cold war, whenever a Soviet official was asked about human rights in
the USSR or such, the immediate response would be "In the USA they lynch
niggers!"
what a classy remark.
look, we get it. you don't like how unix does file i/o, you don't
want
* Peter da Silva [2006-12-19 14:00]:
> On Dec 18, 2006, at 7:43 PM, A. Pagaltzis wrote:
> >#!/bin/sh
> >tee ${1+"$@"} < /dev/null
> >exec rm ${1+"$@"}
>
> That unnecessarily creates the file if it doesn't exist.
Curses. In my haste to get rid of the loop, I missed the -f.
(To be hon
On 19/12/06, Jarkko Hietaniemi wrote:
You hate them until your code needs to work in medieval environments.
Shell scripts: setting castles on fire and shooting people in the
throat with arrows since 1284.
--
Earle Martin
http://downlode.org/
http://purl.org/net/earlemartin/
>> # purge - really remove a file!
>>>
>>> for i
>>> do [ -f $i ] && > $i
>>> done
>>> exec rm ${1+"$@"}
>> #!/bin/sh
>> tee ${1+"$@"} < /dev/null
>> exec rm ${1+"$@"}
>
> Why-oh-why are vile constructs like ${1+"$@"} still being used? This
> isn't 1985 any more. In any modern shell
So if Windows does it bad, does it justify whatever Unix does, or
should we compare to the sensible thing to do instead?
If you can come up with something other than what UNIX does that's not
more hateful than what UNIX does, let's hear it. I've used more
operating systems over the past 30 yea
I don't see a "duplicate writer".
The shell and cat both have the file open for writing.
% sh longrunningprogram.sh > /tmp/stuff &
% rm /tmp/stuff
/tmp/stuff: file is used by longrunningprogram.sh [pid 134]
That leads to temp files NOT getting deleted when they should.
What I was saying i
On Dec 18, 2006, at 7:43 PM, A. Pagaltzis wrote:
#!/bin/sh
tee ${1+"$@"} < /dev/null
exec rm ${1+"$@"}
That unnecessarily creates the file if it doesn't exist. Which could be
very hateful in some cases. :)
On Tue, Dec 19, 2006 at 02:43:57AM +0100, A. Pagaltzis wrote:
> * Peter da Silva [2006-12-18 22:15]:
> > Wouldn't this solve the original problem?
>
> Not only would it solve it, it actually works better: you don't
> need to terminate any process in order to recover the disk space
> occupied by f
This reminds me of another hate: revoke(). It appears to be a nice useful
system call for situations like forcibly deleting files, but sadly it was
a quick hack to make terminals a bit more secure and doesn't work for
anything else.
Tony.
--
f.a.n.finchhttp://dotat.at/
GERMAN BIGHT: WEST VEER
Suppose someone ships a powerful GUI tool (a thin layer of Tcl/Tk on top of a
pile of incomplete and obscure command line programs), showing a list of files
with plain text comments for each file.
Suppose this GUI tool is so powerful it won't let you:
* copy & paste text (unless it's the /enti
On 19/12/06, Yossi Kreinin wrote:
>
>>I'm a programmer. My program created a big file. Give me the
>>POWER to *DELETE* *MY* *FILE*!!
>
>
> On Windows, you'd be told the file is busy and it wouldn't be
> deleted. How is that giving you the POWER to DELETE. YOUR. FILE?
>
At least Windows fans are
This is very sweet of Unix.
Indeed.
* Why is it sensible to allow to truncate a file someone has opened?
Why not?
if you want to do it, go ahead. the system is not your nanny.
* Especially if you don't allow to remove such files?
* Or, more specifically, you ALLOW to remove such files, but
A. Pagaltzis wrote:
Not only would it solve it, it actually works better: you don't
need to terminate any process in order to recover the disk space
occupied by files it has opened.
Yeah, that's better - no need to terminate processes! Fuck those processes. They
think they can use my files,
I'm a programmer. My program created a big file. Give me the
POWER to *DELETE* *MY* *FILE*!!
On Windows, you'd be told the file is busy and it wouldn't be
deleted. How is that giving you the POWER to DELETE. YOUR. FILE?
At least Windows fans aren't arguing it's "powerful", just that it's u
% sh randomscript.sh > file
cat: duplicate writer
% cat randomscript.sh
#!/bin/sh
cat ~/.headerfile
anotherscript.sh
...
%
I don't see a "duplicate writer". If the point is that I don't, but there is,
somewhere down the guts - well, I agree that Unix shell scripts are not much fun
to debu
* Peter da Silva [2006-12-18 22:15]:
> Wouldn't this solve the original problem?
Not only would it solve it, it actually works better: you don't
need to terminate any process in order to recover the disk space
occupied by files it has opened.
> #!/bin/sh
>
> # purge - really remove a file!
>
>
22 matches
Mail list logo
