Enrico Forestieri wrote:
> Funny that you mention that:
> 
> host1> tail --version
> tail (GNU coreutils) 5.97
> ...
> host1> tail +20 foo
> [commands succeeds, showing last lines of foo starting from line 20]
> 
> host2> tail --version
> tail (GNU coreutils) 8.5
> ...
> host2> tail +20 foo
> tail: cannot open `+20' for reading: No such file or directory

core of my complaint was that changing semantics of traditional
switch is pita and will be hardly changed by disputing nitpicks
of selected examples inside coreutils.

> > its really not a question
> > of 'simply adding -f' if you use lyx routinely for zilion
> > of scripts (not to mention that other users must find
> > why the hell the chain of scripts do not work anymore out
> > of the blue...)
> 
> This is documented, so, if you read announcements, it does not come
> out of the blue.

yep, i'm a perfect counter-example ;) although having much better knowledge
of the changes and the annoucement file itself then ordinary user it came out
of the blue. the news just state adding '-f' flag without any warn of 
regression.

>However, what could be done is initializing force_overwrite
> at startup by using the rc setting \export_overwrite, which is currently
> used only for the GUI. In this way, one could decide what to do by default
> even in the absence of a -f switch. I still think that the current one is
> the correct behavior, though, and see this solution as a kludge.
> 
> > i'm sorry coming with this complaint in this phase, but i still think
> > we should keep that "-e" overwrites the main file.
> 
> Strongly disagree.

could you elaborate why strong disagreement? another utils i'm currently using
around lyx work also like that - pdflatex rewrites ouput, dvips too. you are
strongly disagree with their doing also?
its really no fun to scan all the scripts in various projects manually checking
usages of lyx calls and be worried what has been overlooked. so i would like
to hear that strong argument why we change this.

the user bug report was asking for slightly different thing - not overwriting
figure accompanying the lyx file. thats dataloss and needed to be fixed indeed,
but overwriting .pdf result is completely different issue.

pavel

Reply via email to