Re: Branch regression?
Enrico Forestieri wrote: On Thu, Jul 15, 2010 at 01:32:33PM +0200, Pavel Sanda wrote: Enrico Forestieri wrote: Please, find attached the corresponding patches. - overwrite-1.diff implements behavior 1 - overwrite-2.diff implements behavior 2 The patch obtaining more votes will be applied. from what i have counted you won. I would like to have a higher turnout of voters. I also think that this poll should not be limited to developers. whosoever wanted to add his comment did it, so lets move on. pavel
Re: Branch regression?
On Sat, Jul 17, 2010 at 01:49:38PM +0200, Pavel Sanda wrote: Enrico Forestieri wrote: On Thu, Jul 15, 2010 at 01:32:33PM +0200, Pavel Sanda wrote: Enrico Forestieri wrote: Please, find attached the corresponding patches. - overwrite-1.diff implements behavior 1 - overwrite-2.diff implements behavior 2 The patch obtaining more votes will be applied. from what i have counted you won. I would like to have a higher turnout of voters. I also think that this poll should not be limited to developers. whosoever wanted to add his comment did it, so lets move on. OK. However, as it seems I am the only one with a strong preference for (1), whereas both you and at least another user strongly prefer (2), I am going to apply this last patch. The only problem would be that I have also to deal with the -f main switch, as it was already advertised in 1.6.7. This would also be logical, as if one sets LYX_FORCE_OVERWRITE=none, there should be a way to override it without being forced to use -f all. -- Enrico
Re: Branch regression?
Enrico Forestieri wrote: The patch obtaining more votes will be applied. from what i have counted you won. I would like to have a higher turnout of voters. I also think that this poll should not be limited to developers. whosoever wanted to add his comment did it, so lets move on. OK. However, as it seems I am the only one with a strong preference for (1), whereas both you and at least another user strongly prefer (2), I am going to apply this last patch. The only problem would be that I have also to deal with the -f main switch, as it was already advertised in 1.6.7. This would also be logical, as if one sets LYX_FORCE_OVERWRITE=none, there should be a way to override it without being forced to use -f all. as i have said i accept both. my strongness was for not-to-break backward compatibility. once i was not able to defend 1.6.7 without this change people will be hit any way. pavel
Re: Branch regression?
Enrico Forestieri wrote: > On Thu, Jul 15, 2010 at 01:32:33PM +0200, Pavel Sanda wrote: > > Enrico Forestieri wrote: > > > Please, find attached the corresponding patches. > > > > > > - overwrite-1.diff implements behavior 1 > > > - overwrite-2.diff implements behavior 2 > > > > > > The patch obtaining more votes will be applied. > > > > from what i have counted you won. > > I would like to have a higher turnout of voters. I also think that > this poll should not be limited to developers. whosoever wanted to add his comment did it, so lets move on. pavel
Re: Branch regression?
On Sat, Jul 17, 2010 at 01:49:38PM +0200, Pavel Sanda wrote: > Enrico Forestieri wrote: > > On Thu, Jul 15, 2010 at 01:32:33PM +0200, Pavel Sanda wrote: > > > Enrico Forestieri wrote: > > > > Please, find attached the corresponding patches. > > > > > > > > - overwrite-1.diff implements behavior 1 > > > > - overwrite-2.diff implements behavior 2 > > > > > > > > The patch obtaining more votes will be applied. > > > > > > from what i have counted you won. > > > > I would like to have a higher turnout of voters. I also think that > > this poll should not be limited to developers. > > whosoever wanted to add his comment did it, so lets move on. OK. However, as it seems I am the only one with a strong preference for (1), whereas both you and at least another user strongly prefer (2), I am going to apply this last patch. The only problem would be that I have also to deal with the "-f main" switch, as it was already advertised in 1.6.7. This would also be logical, as if one sets LYX_FORCE_OVERWRITE=none, there should be a way to override it without being forced to use "-f all". -- Enrico
Re: Branch regression?
Enrico Forestieri wrote: > > > > > The patch obtaining more votes will be applied. > > > > > > > > from what i have counted you won. > > > > > > I would like to have a higher turnout of voters. I also think that > > > this poll should not be limited to developers. > > > > whosoever wanted to add his comment did it, so lets move on. > > OK. However, as it seems I am the only one with a strong preference for (1), > whereas both you and at least another user strongly prefer (2), I am going > to apply this last patch. The only problem would be that I have also to deal > with the "-f main" switch, as it was already advertised in 1.6.7. > This would also be logical, as if one sets LYX_FORCE_OVERWRITE=none, there > should be a way to override it without being forced to use "-f all". as i have said i accept both. my strongness was for not-to-break backward compatibility. once i was not able to defend 1.6.7 without this change people will be hit any way. pavel
Re: Branch regression?
Enrico Forestieri wrote: Please, find attached the corresponding patches. - overwrite-1.diff implements behavior 1 - overwrite-2.diff implements behavior 2 The patch obtaining more votes will be applied. from what i have counted you won. pavel
Re: Branch regression?
On Thu, Jul 15, 2010 at 01:32:33PM +0200, Pavel Sanda wrote: Enrico Forestieri wrote: Please, find attached the corresponding patches. - overwrite-1.diff implements behavior 1 - overwrite-2.diff implements behavior 2 The patch obtaining more votes will be applied. from what i have counted you won. I would like to have a higher turnout of voters. I also think that this poll should not be limited to developers. -- Enrico
Re: Branch regression?
Enrico Forestieri wrote: > Please, find attached the corresponding patches. > > - overwrite-1.diff implements behavior 1 > - overwrite-2.diff implements behavior 2 > > The patch obtaining more votes will be applied. from what i have counted you won. pavel
Re: Branch regression?
On Thu, Jul 15, 2010 at 01:32:33PM +0200, Pavel Sanda wrote: > Enrico Forestieri wrote: > > Please, find attached the corresponding patches. > > > > - overwrite-1.diff implements behavior 1 > > - overwrite-2.diff implements behavior 2 > > > > The patch obtaining more votes will be applied. > > from what i have counted you won. I would like to have a higher turnout of voters. I also think that this poll should not be limited to developers. -- Enrico
Re: Branch regression?
On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote: you really mean lyx -e lyx foo.lyx seriously? :) its just pretty normal that if you ask on command line to write output over the input file it gets overwritten like the infamous 'cat file1 file2 file1' mistake. don't see the swith in pdflatex but dvips file.dvi -o file.dvi will of course overwrite input - and thats correct. While it is clear from your cat or dvips examples that the input file is going to be overwritten, this is not the case in my lyx example. commands can be changed if they are wrong, but the exotic case invented just for this debate like lyx -e lyx foo.lyx is hardly enough reason. it looks as fixing acrobatic usecases never reported by anybody for the price of introducing new problems. typical usecase is output to dvi/ps/pdf so the question about some real problem our previous scheme causes to users remains (except the fixed issue with overwriting eps figure ;). I think you don't get the principle. You import a .tex file in lyx, then you inadvertently use lyx -e latex on that file. Your original file would now be gone. i still maintain that the backward compatibility will cause less user's frustration for this particular switch (ie default RC setting would need to be set on main file overwrite) than new gun-discharged-course but i let the responsibility on Juergen or anybody else who want to comment on :) So, let's have a poll: 1) Leave things as they are (need -f to overwrite) 2) The main file should always be overwritten 3) If no -f switch is given, use preferences settings for overwriting I vote for 1) -- Enrico
Re: Branch regression?
Am 14.07.2010 um 10:15 schrieb Enrico Forestieri: On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote: you really mean lyx -e lyx foo.lyx seriously? :) its just pretty normal that if you ask on command line to write output over the input file it gets overwritten like the infamous 'cat file1 file2 file1' mistake. don't see the swith in pdflatex but dvips file.dvi -o file.dvi will of course overwrite input - and thats correct. While it is clear from your cat or dvips examples that the input file is going to be overwritten, this is not the case in my lyx example. One remark here (nitpick): In the first example cat is not the program which overwrites the original. It is the shell - and to avoid that stupid mistake they introduced the variable noclobber. When it is set and if your scripts assume overwrite of already existent files is ok they fail - out of the blue! Not only if input and output are the same... every time one tries to overwrite an existent file with redirection. Of course you may use the redirection operator | instead to fix your script... commands can be changed if they are wrong, but the exotic case invented just for this debate like lyx -e lyx foo.lyx is hardly enough reason. it looks as fixing acrobatic usecases never reported by anybody for the price of introducing new problems. typical usecase is output to dvi/ps/pdf so the question about some real problem our previous scheme causes to users remains (except the fixed issue with overwriting eps figure ;). I think you don't get the principle. You import a .tex file in lyx, then you inadvertently use lyx -e latex on that file. Your original file would now be gone. i still maintain that the backward compatibility will cause less user's frustration for this particular switch (ie default RC setting would need to be set on main file overwrite) than new gun-discharged-course but i let the responsibility on Juergen or anybody else who want to comment on :) So, let's have a poll: 1) Leave things as they are (need -f to overwrite) 2) The main file should always be overwritten 3) If no -f switch is given, use preferences settings for overwriting I vote for 1 (but I don't use that feature until now). Stephan
Re: Branch regression?
Enrico Forestieri wrote: commands can be changed if they are wrong, but the exotic case invented just for this debate like lyx -e lyx foo.lyx is hardly enough reason. it looks as fixing acrobatic usecases never reported by anybody for the price of introducing new problems. typical usecase is output to dvi/ps/pdf so the question about some real problem our previous scheme causes to users remains (except the fixed issue with overwriting eps figure ;). I think you don't get the principle. You import a .tex file in lyx, then you inadvertently use lyx -e latex on that file. Your original file would now be gone. ok thats better than -e lyx example... i still maintain that the backward compatibility will cause less user's frustration for this particular switch (ie default RC setting would need to be set on main file overwrite) than new gun-discharged-course but i let the responsibility on Juergen or anybody else who want to comment on :) So, let's have a poll: 1) Leave things as they are (need -f to overwrite) 2) The main file should always be overwritten 3) If no -f switch is given, use preferences settings for overwriting as i said i accept both 2 or 3 but will strongly opose to 1 since it not only changes the behaviour but also make impossible for anybody to reuse old scripts without revisiting each of them. since its pretty clear that you are strongly against 2 and me against 1 i propose 3 so we can stop the flamewar. pavel
Re: Branch regression?
Stephan Witt wrote: One remark here (nitpick): In the first example cat is not the program which overwrites the original. It is the shell - and to avoid that stupid mistake they introduced the variable noclobber. When it is set and if your scripts assume overwrite of already existent files is ok they fail - out of the blue! your example would be appropriate if noclobber is set out of the blue by default in my distribution and all bash scripts around the world which suppose overwrite stop to work. the would be big fun and i hear the scream ;) pavel
Re: Branch regression?
Am 14.07.2010 um 11:57 schrieb Pavel Sanda: Stephan Witt wrote: One remark here (nitpick): In the first example cat is not the program which overwrites the original. It is the shell - and to avoid that stupid mistake they introduced the variable noclobber. When it is set and if your scripts assume overwrite of already existent files is ok they fail - out of the blue! your example would be appropriate if noclobber is set out of the blue by default in my distribution and all bash scripts around the world which suppose overwrite stop to work. the would be big fun and i hear the scream ;) Yes. I made this experience long ago. Not that the distribution had this default... the sysadmin wanted to be helpful and protect the users :-) So the noclobber was set before the start of any user script globally. So I had to fix my scripts... :( Anyway, I have no strong opinion here. And I can follow both sides... Stephan
Re: Branch regression?
Jürgen Spitzmüller wrote: Pavel Sanda wrote: i still maintain that the backward compatibility will cause less user's frustration for this particular switch (ie default RC setting would need to be set on main file overwrite) than new gun-discharged-course but i let the responsibility on Juergen or anybody else who want to comment on :) I don't stop 1.6.7 because of this. which means that you dont want to postpone it for other discussions or that Enricos's patch is no-go for 1.6.7? pavel
Re: Branch regression?
On Wed, Jul 14, 2010 at 11:45:54AM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
So, let's have a poll:
1) Leave things as they are (need -f to overwrite)
2) The main file should always be overwritten
3) If no -f switch is given, use preferences settings for overwriting
as i said i accept both 2 or 3 but will strongly opose to 1 since it not only
changes the behaviour but also make impossible for anybody to reuse old
scripts
without revisiting each of them.
since its pretty clear that you are strongly against 2 and me against 1 i
propose 3 so we can stop the flamewar.
A fourth option could be using an env var, say LYX_EXPORT_OVERWRITE, with
possible values {all,main,none}. This would disentangle the GUI export from
the command line export.
--
Enrico
Re: Branch regression?
Pavel Sanda wrote: I don't stop 1.6.7 because of this. which means that you dont want to postpone it for other discussions or that Enricos's patch is no-go for 1.6.7? the former. On the patch itself, I do not have a strong opinion. Jürgen
Re: Branch regression?
Jürgen Spitzmüller wrote: Pavel Sanda wrote: I don't stop 1.6.7 because of this. which means that you dont want to postpone it for other discussions or that Enricos's patch is no-go for 1.6.7? the former. On the patch itself, I do not have a strong opinion. ok unless Enrico is not against i would be thaknful if we could put his patch into branch now... pavel
Re: Branch regression?
Pavel Sanda wrote: ok unless Enrico is not against i would be thaknful if we could put his patch into branch now... As said, I do not want to unfreeze 1.6.7svn again. Jürgen
Re: Branch regression?
Jürgen Spitzmüller wrote: Pavel Sanda wrote: ok unless Enrico is not against i would be thaknful if we could put his patch into branch now... As said, I do not want to unfreeze 1.6.7svn again. aha i misunderstood. pavel
Re: Branch regression?
Enrico Forestieri wrote:
as i said i accept both 2 or 3 but will strongly opose to 1 since it not
only
changes the behaviour but also make impossible for anybody to reuse old
scripts
without revisiting each of them.
since its pretty clear that you are strongly against 2 and me against 1 i
propose 3 so we can stop the flamewar.
A fourth option could be using an env var, say LYX_EXPORT_OVERWRITE, with
possible values {all,main,none}. This would disentangle the GUI export from
the command line export.
what would be the implicit value? if 'none', its kind of equivalent with the rc
patch.
if 'main' then i like it more, of course ;)
pavel
Re: Branch regression?
On Wed, Jul 14, 2010 at 02:04:16PM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
as i said i accept both 2 or 3 but will strongly opose to 1 since it not
only
changes the behaviour but also make impossible for anybody to reuse old
scripts
without revisiting each of them.
since its pretty clear that you are strongly against 2 and me against 1 i
propose 3 so we can stop the flamewar.
A fourth option could be using an env var, say LYX_EXPORT_OVERWRITE, with
possible values {all,main,none}. This would disentangle the GUI export from
the command line export.
what would be the implicit value? if 'none', its kind of equivalent with the
rc patch.
if 'main' then i like it more, of course ;)
Yes, of course none would be the default if anything other than all or
main is specified. See the attached patch. I like this solution much more
than 3, because it is more flexible and safer.
LYX_FORCE_OVERWRITE=main lyx -e dvi foo.lyx
does what you want.
--
Enrico
Index: src/LyX.cpp
===
--- src/LyX.cpp (revisione 34893)
+++ src/LyX.cpp (copia locale)
@@ -736,9 +736,17 @@ bool LyX::init()
if (queryUserLyXDir(package().explicit_user_support()))
reconfigureUserLyXDir();
- // no need for a splash when there is no GUI
if (!use_gui) {
+ // no need for a splash when there is no GUI
first_start = false;
+ // If no -f switch was given, check LYX_FORCE_OVERWRITE
+ if (force_overwrite == NO_FILES) {
+ string const what = getEnv(LYX_FORCE_OVERWRITE);
+ if (what == all)
+ force_overwrite = ALL_FILES;
+ else if (what == main)
+ force_overwrite = MAIN_FILE;
+ }
}
// This one is generated in user_support directory by lib/configure.py.
Re: Branch regression?
Am 14.07.2010 um 14:25 schrieb Enrico Forestieri:
On Wed, Jul 14, 2010 at 02:04:16PM +0200, Pavel Sanda wrote:
Enrico Forestieri wrote:
as i said i accept both 2 or 3 but will strongly opose to 1 since it not
only
changes the behaviour but also make impossible for anybody to reuse old
scripts
without revisiting each of them.
since its pretty clear that you are strongly against 2 and me against 1 i
propose 3 so we can stop the flamewar.
A fourth option could be using an env var, say LYX_EXPORT_OVERWRITE, with
possible values {all,main,none}. This would disentangle the GUI export from
the command line export.
what would be the implicit value? if 'none', its kind of equivalent with the
rc patch.
if 'main' then i like it more, of course ;)
Yes, of course none would be the default if anything other than all or
main is specified. See the attached patch. I like this solution much more
than 3, because it is more flexible and safer.
LYX_FORCE_OVERWRITE=main lyx -e dvi foo.lyx
does what you want.
Or in crontab (hypothetic example):
LYX_FORCE_OVERWRITE=main
0 6 * * * $HOME/bin/lyx-doc-update.sh
Stephan
Re: Branch regression?
Enrico Forestieri wrote: what would be the implicit value? if 'none', its kind of equivalent with the rc patch. if 'main' then i like it more, of course ;) Yes, of course none would be the default if anything other than all or main is specified. See the attached patch. I like this solution much more than 3, because it is more flexible and safer. ok, lets put it into trunk and backport to 1.6.8 once branch is unfreezed again. Juergen, status file for 1.6.7 does not clearly warns about the issue, you maybe want at least put some note about commandline incompatibility into web annoucement. pavel
Re: Branch regression?
On 14/07/2010 4:15 AM, Enrico Forestieri wrote: On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote: you really mean lyx -e lyx foo.lyx seriously? :) its just pretty normal that if you ask on command line to write output over the input file it gets overwritten like the infamous 'cat file1 file2 file1' mistake. don't see the swith in pdflatex but dvips file.dvi -o file.dvi will of course overwrite input - and thats correct. While it is clear from your cat or dvips examples that the input file is going to be overwritten, this is not the case in my lyx example. commands can be changed if they are wrong, but the exotic case invented just for this debate like lyx -e lyx foo.lyx is hardly enough reason. it looks as fixing acrobatic usecases never reported by anybody for the price of introducing new problems. typical usecase is output to dvi/ps/pdf so the question about some real problem our previous scheme causes to users remains (except the fixed issue with overwriting eps figure ;). I think you don't get the principle. You import a .tex file in lyx, then you inadvertently use lyx -e latex on that file. Your original file would now be gone. It is hard to believe that you would /inadvertently/ use the command line. If you do, then it was your mistake. But wary users could have a shortcut: alias lyx='lyx -f=none' i still maintain that the backward compatibility will cause less user's frustration for this particular switch (ie default RC setting would need to be set on main file overwrite) than new gun-discharged-course but i let the responsibility on Juergen or anybody else who want to comment on :) So, let's have a poll: 1) Leave things as they are (need -f to overwrite) 2) The main file should always be overwritten 3) If no -f switch is given, use preferences settings for overwriting I vote for 1) I vote for 2 (in case users get a vote). -- Julien
Re: Branch regression?
On 07/14/2010 08:25 AM, Enrico Forestieri wrote: LYX_FORCE_OVERWRITE=main lyx -e dvi foo.lyx does what you want. and, of course, you can export LYX_FORCE_OVERWRITE=main from .bash_profile if you want. rh
Re: Branch regression?
On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote: It is hard to believe that you would /inadvertently/ use the command line. If you do, then it was your mistake. But wary users could have a shortcut: alias lyx='lyx -f=none' I think you're missing the point, too. On July 14 you import the .tex file. On July 20 you try to export to latex from command line. Export fails because you had forgotten that the original file was still there. You investigate and say gosh, I had left there the original file, luckily LyX saved my day :) I vote for 2 (in case users get a vote). Then, I think you will like the env var approach that lets you live as dangerously as you like :) -- Enrico
Re: Branch regression?
On 14/07/2010 11:52 AM, Enrico Forestieri wrote: On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote: It is hard to believe that you would /inadvertently/ use the command line. If you do, then it was your mistake. But wary users could have a shortcut: alias lyx='lyx -f=none' I think you're missing the point, too. On July 14 you import the .tex file. On July 20 you try to export to latex from command line. Export fails because you had forgotten that the original file was still there. You investigate and say gosh, I had left there the original file, luckily LyX saved my day :) I vote for 2 (in case users get a vote). Then, I think you will like the env var approach that lets you live as dangerously as you like :) Just to be clear, I did not miss the point. If I cp /path/file.tex . and I forgot that there was already a file.tex in the current folder, too bad. That's my mistake. If I want to avoid that mistake from ever occuring, I run cp with the -i (interactive) flag. Or I define an alias which does so. Note that cp also has a -n (don't overwrite) flag. This seems pretty pointless for a cp command, no? Imagine if this was the default behavior. cp /path/file.tex . does nothing... sounds strange, no? I understand that overwriting other files such as eps files during latex export is an important issue, but it is a different issue. Anyway I am fine with the environment variable solution, but I would vote for a -safe or -f=none switch and the default would be -f-main. Regards, Julien
Re: Branch regression?
Enrico Forestieri wrote: On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote: It is hard to believe that you would /inadvertently/ use the command line. If you do, then it was your mistake. But wary users could have a shortcut: alias lyx='lyx -f=none' I think you're missing the point, too. On July 14 you import the .tex file. On July 20 you try to export to latex from command line. Export fails because you had forgotten that the original file was still there. You investigate and say gosh, I had left there the original file, luckily LyX saved my day :) I vote for 2 (in case users get a vote). Then, I think you will like the env var approach that lets you live as dangerously as you like :) he would write 3 in that case, its almost the same ;) there are two distinct points to be distinguished: 1. to allow users to be where they want - either on the safe side or on the danger side. both your patches satisfy this. 2. to setup the implicit behaviour, when the user didn't choose anything. i think nobody has problem with 1. both opinions on point 2. have their up and downs, from what i distilled: args from the safety side: - you can lost some data args from the danger side: - the real complaint we ever got is fixed, by main. the exports to .tex and .lyx can happen but they seem to be fabricated just for this discussion. - we break compatility for launching lyx in batch jobs. part of it is repaired by proposed patches. since Juergen gave red flag for 1.6.7, we are lost anyway, thats why i'm not so vocal anymore :) - its pretty standard that linux command line tools are on the danger side by default even when they allow globbing etc... feel free to add points on safe side ;) pavel
Re: Branch regression?
Pavel Sanda wrote: Juergen, status file for 1.6.7 does not clearly warns about the issue, you maybe want at least put some note about commandline incompatibility into web annoucement. I think this can go into the wiki version of the RELEASE_NOTES. Jürgen
Re: Branch regression?
On Wed, Jul 14, 2010 at 12:38:41PM -0400, Julien Rioux wrote: Note that cp also has a -n (don't overwrite) flag. This seems pretty pointless for a cp command, no? Imagine if this was the default behavior. cp /path/file.tex . does nothing... sounds strange, no? $ lyx -e latex foo.lyx Overwrite file? The file ~/foo.tex already exists. Do you want to overwrite that file? Assuming answer is Keep file Overwrite Overwrite all Cancel export I don't think that fits the description does nothing. I understand that overwriting other files such as eps files during latex export is an important issue, but it is a different issue. Anyway I am fine with the environment variable solution, but I would vote for a -safe or -f=none switch and the default would be -f-main. Well, I think that is a matter of philosophical approach. I think that having to do something for causing damage is better than having to do something for avoiding damage. -- Enrico
Re: Branch regression?
On Wed, Jul 14, 2010 at 06:41:13PM +0200, Pavel Sanda wrote: Enrico Forestieri wrote: On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote: It is hard to believe that you would /inadvertently/ use the command line. If you do, then it was your mistake. But wary users could have a shortcut: alias lyx='lyx -f=none' I think you're missing the point, too. On July 14 you import the .tex file. On July 20 you try to export to latex from command line. Export fails because you had forgotten that the original file was still there. You investigate and say gosh, I had left there the original file, luckily LyX saved my day :) I vote for 2 (in case users get a vote). Then, I think you will like the env var approach that lets you live as dangerously as you like :) he would write 3 in that case, its almost the same ;) there are two distinct points to be distinguished: 1. to allow users to be where they want - either on the safe side or on the danger side. both your patches satisfy this. 2. to setup the implicit behaviour, when the user didn't choose anything. i think nobody has problem with 1. both opinions on point 2. have their up and downs, from what i distilled: args from the safety side: - you can lost some data args from the danger side: - the real complaint we ever got is fixed, by main. the exports to .tex and .lyx can happen but they seem to be fabricated just for this discussion. - we break compatility for launching lyx in batch jobs. part of it is repaired by proposed patches. since Juergen gave red flag for 1.6.7, we are lost anyway, thats why i'm not so vocal anymore :) - its pretty standard that linux command line tools are on the danger side by default even when they allow globbing etc... feel free to add points on safe side ;) I did not imagine I could have caused such a reaction for a safety measure that I thought could have been quite easily overcomed. I am going to do nothing until a *clear* consensus emerges about what should be the default behavior when exporting from command line. I think it boils down to: 1) Never ovewrite files, unless explicitely told so 2) The main file should be always overwritten -- Enrico
Re: Branch regression?
On 14/07/2010 1:10 PM, Enrico Forestieri wrote: On Wed, Jul 14, 2010 at 12:38:41PM -0400, Julien Rioux wrote: Note that cp also has a -n (don't overwrite) flag. This seems pretty pointless for a cp command, no? Imagine if this was the default behavior. cp /path/file.tex . does nothing... sounds strange, no? $ lyx -e latex foo.lyx Overwrite file? The file ~/foo.tex already exists. Do you want to overwrite that file? Assuming answer isKeep file Overwrite Overwriteall Cancel export I don't think that fits the description does nothing. I get that message, but lyx proceeds without waiting for my interaction. Keep file is assumed. What am I doing wrong? (using ubuntu and latest branch r34829) I understand that overwriting other files such as eps files during latex export is an important issue, but it is a different issue. Anyway I am fine with the environment variable solution, but I would vote for a -safe or -f=none switch and the default would be -f-main. Well, I think that is a matter of philosophical approach. I think that having to do something for causing damage is better than having to do something for avoiding damage. That's why your poll is a good idea. I don't want to flame, I just though you wanted to hear some opinions. My view is, I understand the risks, I still prefer to live dangerously! (and too lazy to change my scripts and makefiles, I guess) Best, Julien
Re: Branch regression?
On Wed, Jul 14, 2010 at 07:47:56PM +0200, Enrico Forestieri wrote:
I did not imagine I could have caused such a reaction for a safety measure
that I thought could have been quite easily overcomed. I am going to do
nothing until a *clear* consensus emerges about what should be the default
behavior when exporting from command line. I think it boils down to:
1) Never ovewrite files, unless explicitely told so
2) The main file should be always overwritten
Please, find attached the corresponding patches.
- overwrite-1.diff implements behavior 1
- overwrite-2.diff implements behavior 2
The patch obtaining more votes will be applied.
--
Enrico
Index: src/LyX.cpp
===
--- src/LyX.cpp (revisione 34893)
+++ src/LyX.cpp (copia locale)
@@ -736,9 +736,17 @@ bool LyX::init()
if (queryUserLyXDir(package().explicit_user_support()))
reconfigureUserLyXDir();
- // no need for a splash when there is no GUI
if (!use_gui) {
+ // no need for a splash when there is no GUI
first_start = false;
+ // If no -f switch was given, check LYX_FORCE_OVERWRITE
+ if (force_overwrite == NO_FILES) {
+ string const what = getEnv(LYX_FORCE_OVERWRITE);
+ if (what == all)
+ force_overwrite = ALL_FILES;
+ else if (what == main)
+ force_overwrite = MAIN_FILE;
+ }
}
// This one is generated in user_support directory by lib/configure.py.
Index: lyx.1in
===
--- lyx.1in (revisione 34893)
+++ lyx.1in (copia locale)
@@ -124,6 +124,17 @@ The user directory is, in order of prece
.B LYX_LOCALEDIR
can be used to tell LyX where to look for the translations of its GUI
strings in other languages.
+
+.TP
+.B LYX_FORCE_OVERWRITE
+can be used to change the default behavior when exporting from command
+line.
+.PP
+By default, LyX does not overwrite files when exporting from command
+line. This behavior can be changed by setting this environment variable,
+which relieves the need of using the \-f switch. Allowed values are either
+\fBall\fR or \fBmain\fR, with same meaning as for the \-f switch.
+If you set this variable, be careful when exporting.
.SH FILES
.nf
.ta \w'\fILIBDIR\fR/lyxrc.in 'u
Index: src/LyX.cpp
===
--- src/LyX.cpp (revisione 34893)
+++ src/LyX.cpp (copia locale)
@@ -93,7 +93,7 @@ bool use_gui = true;
// Tell what files can be silently overwritten during batch export.
// Possible values are: NO_FILES, MAIN_FILE, ALL_FILES.
-OverwriteFiles force_overwrite = NO_FILES;
+OverwriteFiles force_overwrite = MAIN_FILE;
namespace {
@@ -736,9 +736,17 @@ bool LyX::init()
if (queryUserLyXDir(package().explicit_user_support()))
reconfigureUserLyXDir();
- // no need for a splash when there is no GUI
if (!use_gui) {
+ // no need for a splash when there is no GUI
first_start = false;
+ // If no -f switch was given, check LYX_FORCE_OVERWRITE
+ if (force_overwrite == MAIN_FILE) {
+ string const what = getEnv(LYX_FORCE_OVERWRITE);
+ if (what == all)
+ force_overwrite = ALL_FILES;
+ else if (what == none)
+ force_overwrite = NO_FILES;
+ }
}
// This one is generated in user_support directory by lib/configure.py.
@@ -1012,9 +1020,9 @@ int parse_help(string const , string co
where fmt is the import format of choice\n
and file.xxx is the file to be imported.\n
\t-f [--force-overwrite] what\n
- where what is either `all' or `main'.\n
- Using `all', all files are overwritten
during\n
- a batch export, otherwise only the main
file will be.\n
+ where what is either `all' or `none'.\n
+ Using `all', all ancillary files are
overwritten during a\n
+ batch export, otherwise none will be (main
file included).\n
Anything else is equivalent to `all', but
is not consumed.\n
\t-batch execute commands without launching GUI and
exit.\n
\t-versionsummarize version and build info\n
@@ -1123,8 +1131,8 @@ int parse_force(string const arg, stri
if (arg == all) {
force_overwrite = ALL_FILES;
return 1;
- } else if (arg == main) {
-
Re: Branch regression?
On 07/14/2010 02:47 PM, Enrico Forestieri wrote: On Wed, Jul 14, 2010 at 07:47:56PM +0200, Enrico Forestieri wrote: I did not imagine I could have caused such a reaction for a safety measure that I thought could have been quite easily overcomed. I am going to do nothing until a *clear* consensus emerges about what should be the default behavior when exporting from command line. I think it boils down to: 1) Never ovewrite files, unless explicitely told so 2) The main file should be always overwritten Please, find attached the corresponding patches. - overwrite-1.diff implements behavior 1 - overwrite-2.diff implements behavior 2 The patch obtaining more votes will be applied. I don't have insanely strong views about this, but I tend to agree with Enrico and so would vote for (1). I understand that it will cause some heartache for people who use a lot of scripts, but if the environment variable is checked---is that in this patch?---then it's easy to make one's own system behave globally as if we had gone with (2). That seems good enough to me, and it protects people from doing something dumb. Richard
Re: Branch regression?
On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote: > > you really mean "lyx -e lyx foo.lyx" seriously? :) its just pretty normal that > if you ask on command line to write output over the input file it gets > overwritten > like the infamous 'cat file1 file2 > file1' mistake. don't see the swith in > pdflatex > but "dvips file.dvi -o file.dvi" will of course overwrite input - and thats > correct. While it is clear from your cat or dvips examples that the input file is going to be overwritten, this is not the case in my lyx example. > commands can be changed if they are wrong, but the exotic case invented just > for > this debate like "lyx -e lyx foo.lyx" is hardly enough reason. > it looks as fixing acrobatic usecases never reported by anybody for > the price of introducing new problems. typical usecase is output to dvi/ps/pdf > so the question about some real problem our previous scheme causes to users > remains (except the fixed issue with overwriting eps figure ;). I think you don't get the principle. You import a .tex file in lyx, then you inadvertently use "lyx -e latex" on that file. Your original file would now be gone. > i still maintain that the backward compatibility will cause less user's > frustration for this particular switch (ie default RC setting would need to be > set on main file overwrite) than new gun-discharged-course but i let the > responsibility on Juergen or anybody else who want to comment on :) So, let's have a poll: 1) Leave things as they are (need -f to overwrite) 2) The main file should always be overwritten 3) If no -f switch is given, use preferences settings for overwriting I vote for 1) -- Enrico
Re: Branch regression?
Am 14.07.2010 um 10:15 schrieb Enrico Forestieri: > On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote: >> >> you really mean "lyx -e lyx foo.lyx" seriously? :) its just pretty normal >> that >> if you ask on command line to write output over the input file it gets >> overwritten >> like the infamous 'cat file1 file2 > file1' mistake. don't see the swith in >> pdflatex >> but "dvips file.dvi -o file.dvi" will of course overwrite input - and thats >> correct. > > While it is clear from your cat or dvips examples that the input file > is going to be overwritten, this is not the case in my lyx example. One remark here (nitpick): In the first example "cat" is not the program which overwrites the original. It is the shell - and to avoid that stupid mistake they introduced the variable noclobber. When it is set and if your scripts assume overwrite of already existent files is ok they fail - out of the blue! Not only if input and output are the same... every time one tries to overwrite an existent file with redirection. Of course you may use the redirection operator ">|" instead to fix your script... > >> commands can be changed if they are wrong, but the exotic case invented just >> for >> this debate like "lyx -e lyx foo.lyx" is hardly enough reason. >> it looks as fixing acrobatic usecases never reported by anybody for >> the price of introducing new problems. typical usecase is output to >> dvi/ps/pdf >> so the question about some real problem our previous scheme causes to users >> remains (except the fixed issue with overwriting eps figure ;). > > I think you don't get the principle. You import a .tex file in lyx, then > you inadvertently use "lyx -e latex" on that file. Your original file would > now be gone. > >> i still maintain that the backward compatibility will cause less user's >> frustration for this particular switch (ie default RC setting would need to >> be >> set on main file overwrite) than new gun-discharged-course but i let the >> responsibility on Juergen or anybody else who want to comment on :) > > So, let's have a poll: > > 1) Leave things as they are (need -f to overwrite) > 2) The main file should always be overwritten > 3) If no -f switch is given, use preferences settings for overwriting I vote for 1 (but I don't use that feature until now). Stephan
Re: Branch regression?
Enrico Forestieri wrote: > > commands can be changed if they are wrong, but the exotic case invented > > just for > > this debate like "lyx -e lyx foo.lyx" is hardly enough reason. > > it looks as fixing acrobatic usecases never reported by anybody for > > the price of introducing new problems. typical usecase is output to > > dvi/ps/pdf > > so the question about some real problem our previous scheme causes to users > > remains (except the fixed issue with overwriting eps figure ;). > > I think you don't get the principle. You import a .tex file in lyx, then > you inadvertently use "lyx -e latex" on that file. Your original file would > now be gone. ok thats better than -e lyx example... > > i still maintain that the backward compatibility will cause less user's > > frustration for this particular switch (ie default RC setting would need to > > be > > set on main file overwrite) than new gun-discharged-course but i let the > > responsibility on Juergen or anybody else who want to comment on :) > > So, let's have a poll: > > 1) Leave things as they are (need -f to overwrite) > 2) The main file should always be overwritten > 3) If no -f switch is given, use preferences settings for overwriting as i said i accept both 2 or 3 but will strongly opose to 1 since it not only changes the behaviour but also make impossible for anybody to reuse old scripts without revisiting each of them. since its pretty clear that you are strongly against 2 and me against 1 i propose 3 so we can stop the flamewar. pavel
Re: Branch regression?
Stephan Witt wrote: > One remark here (nitpick): > In the first example "cat" is not the program which overwrites the original. > It is the shell - and to avoid that stupid mistake they introduced the > variable noclobber. > When it is set and if your scripts assume overwrite of already existent files > is ok they fail - out of the blue! your example would be appropriate if noclobber is set out of the blue by default in my distribution and all bash scripts around the world which suppose ">" overwrite stop to work. the would be big fun and i hear the scream ;) pavel
Re: Branch regression?
Am 14.07.2010 um 11:57 schrieb Pavel Sanda: > Stephan Witt wrote: >> One remark here (nitpick): >> In the first example "cat" is not the program which overwrites the original. >> It is the shell - and to avoid that stupid mistake they introduced the >> variable noclobber. >> When it is set and if your scripts assume overwrite of already existent >> files is ok they fail - out of the blue! > > your example would be appropriate if noclobber is set out of the blue by > default in my distribution and all bash > scripts around the world which suppose ">" overwrite stop to work. the would > be big fun and i hear the scream ;) Yes. I made this experience long ago. Not that the distribution had this default... the sysadmin wanted to be helpful and protect the users :-) So the noclobber was set before the start of any user script globally. So I had to "fix" my scripts... :( Anyway, I have no strong opinion here. And I can follow both sides... Stephan
Re: Branch regression?
Jürgen Spitzmüller wrote: > Pavel Sanda wrote: > > i still maintain that the backward compatibility will cause less user's > > frustration for this particular switch (ie default RC setting would need to > > be set on main file overwrite) than new gun-discharged-course but i let > > the responsibility on Juergen or anybody else who want to comment on :) > > I don't stop 1.6.7 because of this. which means that you dont want to postpone it for other discussions or that Enricos's patch is no-go for 1.6.7? pavel
Re: Branch regression?
On Wed, Jul 14, 2010 at 11:45:54AM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > So, let's have a poll:
> >
> > 1) Leave things as they are (need -f to overwrite)
> > 2) The main file should always be overwritten
> > 3) If no -f switch is given, use preferences settings for overwriting
>
> as i said i accept both 2 or 3 but will strongly opose to 1 since it not only
> changes the behaviour but also make impossible for anybody to reuse old
> scripts
> without revisiting each of them.
>
> since its pretty clear that you are strongly against 2 and me against 1 i
> propose 3 so we can stop the flamewar.
A fourth option could be using an env var, say LYX_EXPORT_OVERWRITE, with
possible values {all,main,none}. This would disentangle the GUI export from
the command line export.
--
Enrico
Re: Branch regression?
Pavel Sanda wrote: > > I don't stop 1.6.7 because of this. > > which means that you dont want to postpone it for other discussions or that > Enricos's patch is no-go for 1.6.7? the former. On the patch itself, I do not have a strong opinion. Jürgen
Re: Branch regression?
Jürgen Spitzmüller wrote: > Pavel Sanda wrote: > > > I don't stop 1.6.7 because of this. > > > > which means that you dont want to postpone it for other discussions or that > > Enricos's patch is no-go for 1.6.7? > > the former. On the patch itself, I do not have a strong opinion. ok unless Enrico is not against i would be thaknful if we could put his patch into branch now... pavel
Re: Branch regression?
Pavel Sanda wrote: > ok unless Enrico is not against i would be thaknful if we could put > his patch into branch now... As said, I do not want to unfreeze 1.6.7svn again. Jürgen
Re: Branch regression?
Jürgen Spitzmüller wrote: > Pavel Sanda wrote: > > ok unless Enrico is not against i would be thaknful if we could put > > his patch into branch now... > > As said, I do not want to unfreeze 1.6.7svn again. aha i misunderstood. pavel
Re: Branch regression?
Enrico Forestieri wrote:
> > as i said i accept both 2 or 3 but will strongly opose to 1 since it not
> > only
> > changes the behaviour but also make impossible for anybody to reuse old
> > scripts
> > without revisiting each of them.
> >
> > since its pretty clear that you are strongly against 2 and me against 1 i
> > propose 3 so we can stop the flamewar.
>
> A fourth option could be using an env var, say LYX_EXPORT_OVERWRITE, with
> possible values {all,main,none}. This would disentangle the GUI export from
> the command line export.
what would be the implicit value? if 'none', its kind of equivalent with the rc
patch.
if 'main' then i like it more, of course ;)
pavel
Re: Branch regression?
On Wed, Jul 14, 2010 at 02:04:16PM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > > as i said i accept both 2 or 3 but will strongly opose to 1 since it not
> > > only
> > > changes the behaviour but also make impossible for anybody to reuse old
> > > scripts
> > > without revisiting each of them.
> > >
> > > since its pretty clear that you are strongly against 2 and me against 1 i
> > > propose 3 so we can stop the flamewar.
> >
> > A fourth option could be using an env var, say LYX_EXPORT_OVERWRITE, with
> > possible values {all,main,none}. This would disentangle the GUI export from
> > the command line export.
>
> what would be the implicit value? if 'none', its kind of equivalent with the
> rc patch.
> if 'main' then i like it more, of course ;)
Yes, of course none would be the default if anything other than "all" or
"main" is specified. See the attached patch. I like this solution much more
than 3, because it is more flexible and safer.
LYX_FORCE_OVERWRITE=main lyx -e dvi foo.lyx
does what you want.
--
Enrico
Index: src/LyX.cpp
===
--- src/LyX.cpp (revisione 34893)
+++ src/LyX.cpp (copia locale)
@@ -736,9 +736,17 @@ bool LyX::init()
if (queryUserLyXDir(package().explicit_user_support()))
reconfigureUserLyXDir();
- // no need for a splash when there is no GUI
if (!use_gui) {
+ // no need for a splash when there is no GUI
first_start = false;
+ // If no -f switch was given, check LYX_FORCE_OVERWRITE
+ if (force_overwrite == NO_FILES) {
+ string const what = getEnv("LYX_FORCE_OVERWRITE");
+ if (what == "all")
+ force_overwrite = ALL_FILES;
+ else if (what == "main")
+ force_overwrite = MAIN_FILE;
+ }
}
// This one is generated in user_support directory by lib/configure.py.
Re: Branch regression?
Am 14.07.2010 um 14:25 schrieb Enrico Forestieri:
> On Wed, Jul 14, 2010 at 02:04:16PM +0200, Pavel Sanda wrote:
>> Enrico Forestieri wrote:
as i said i accept both 2 or 3 but will strongly opose to 1 since it not
only
changes the behaviour but also make impossible for anybody to reuse old
scripts
without revisiting each of them.
since its pretty clear that you are strongly against 2 and me against 1 i
propose 3 so we can stop the flamewar.
>>>
>>> A fourth option could be using an env var, say LYX_EXPORT_OVERWRITE, with
>>> possible values {all,main,none}. This would disentangle the GUI export from
>>> the command line export.
>>
>> what would be the implicit value? if 'none', its kind of equivalent with the
>> rc patch.
>> if 'main' then i like it more, of course ;)
>
> Yes, of course none would be the default if anything other than "all" or
> "main" is specified. See the attached patch. I like this solution much more
> than 3, because it is more flexible and safer.
>
> LYX_FORCE_OVERWRITE=main lyx -e dvi foo.lyx
>
> does what you want.
Or in crontab (hypothetic example):
LYX_FORCE_OVERWRITE=main
0 6 * * * $HOME/bin/lyx-doc-update.sh
Stephan
Re: Branch regression?
Enrico Forestieri wrote: > > what would be the implicit value? if 'none', its kind of equivalent with > > the rc patch. > > if 'main' then i like it more, of course ;) > > Yes, of course none would be the default if anything other than "all" or > "main" is specified. See the attached patch. I like this solution much more > than 3, because it is more flexible and safer. ok, lets put it into trunk and backport to 1.6.8 once branch is unfreezed again. Juergen, status file for 1.6.7 does not clearly warns about the issue, you maybe want at least put some note about commandline incompatibility into web annoucement. pavel
Re: Branch regression?
On 14/07/2010 4:15 AM, Enrico Forestieri wrote: On Wed, Jul 14, 2010 at 03:50:50AM +0200, Pavel Sanda wrote: you really mean "lyx -e lyx foo.lyx" seriously? :) its just pretty normal that if you ask on command line to write output over the input file it gets overwritten like the infamous 'cat file1 file2> file1' mistake. don't see the swith in pdflatex but "dvips file.dvi -o file.dvi" will of course overwrite input - and thats correct. While it is clear from your cat or dvips examples that the input file is going to be overwritten, this is not the case in my lyx example. commands can be changed if they are wrong, but the exotic case invented just for this debate like "lyx -e lyx foo.lyx" is hardly enough reason. it looks as fixing acrobatic usecases never reported by anybody for the price of introducing new problems. typical usecase is output to dvi/ps/pdf so the question about some real problem our previous scheme causes to users remains (except the fixed issue with overwriting eps figure ;). I think you don't get the principle. You import a .tex file in lyx, then you inadvertently use "lyx -e latex" on that file. Your original file would now be gone. It is hard to believe that you would /inadvertently/ use the command line. If you do, then it was your mistake. But wary users could have a shortcut: alias lyx='lyx -f=none' i still maintain that the backward compatibility will cause less user's frustration for this particular switch (ie default RC setting would need to be set on main file overwrite) than new gun-discharged-course but i let the responsibility on Juergen or anybody else who want to comment on :) So, let's have a poll: 1) Leave things as they are (need -f to overwrite) 2) The main file should always be overwritten 3) If no -f switch is given, use preferences settings for overwriting I vote for 1) I vote for 2 (in case users get a vote). -- Julien
Re: Branch regression?
On 07/14/2010 08:25 AM, Enrico Forestieri wrote: LYX_FORCE_OVERWRITE=main lyx -e dvi foo.lyx does what you want. and, of course, you can export LYX_FORCE_OVERWRITE=main from .bash_profile if you want. rh
Re: Branch regression?
On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote: > It is hard to believe that you would /inadvertently/ use the command > line. If you do, then it was your mistake. But wary users could have > a shortcut: alias lyx='lyx -f=none' I think you're missing the point, too. On July 14 you import the .tex file. On July 20 you try to export to latex from command line. Export fails because you had forgotten that the original file was still there. You investigate and say "gosh, I had left there the original file, luckily LyX saved my day" :) > I vote for 2 (in case users get a vote). Then, I think you will like the env var approach that lets you live as dangerously as you like :) -- Enrico
Re: Branch regression?
On 14/07/2010 11:52 AM, Enrico Forestieri wrote: On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote: It is hard to believe that you would /inadvertently/ use the command line. If you do, then it was your mistake. But wary users could have a shortcut: alias lyx='lyx -f=none' I think you're missing the point, too. On July 14 you import the .tex file. On July 20 you try to export to latex from command line. Export fails because you had forgotten that the original file was still there. You investigate and say "gosh, I had left there the original file, luckily LyX saved my day" :) I vote for 2 (in case users get a vote). Then, I think you will like the env var approach that lets you live as dangerously as you like :) Just to be clear, I did not miss the point. If I "cp /path/file.tex ." and I forgot that there was already a file.tex in the current folder, too bad. That's my mistake. If I want to avoid that mistake from ever occuring, I run cp with the -i (interactive) flag. Or I define an alias which does so. Note that cp also has a -n (don't overwrite) flag. This seems pretty pointless for a cp command, no? Imagine if this was the default behavior. "cp /path/file.tex ." does nothing... sounds strange, no? I understand that overwriting other files such as eps files during latex export is an important issue, but it is a different issue. Anyway I am fine with the environment variable solution, but I would vote for a -safe or -f=none switch and the default would be -f-main. Regards, Julien
Re: Branch regression?
Enrico Forestieri wrote: > On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote: > > It is hard to believe that you would /inadvertently/ use the command > > line. If you do, then it was your mistake. But wary users could have > > a shortcut: alias lyx='lyx -f=none' > > I think you're missing the point, too. On July 14 you import the .tex > file. On July 20 you try to export to latex from command line. Export > fails because you had forgotten that the original file was still there. > You investigate and say "gosh, I had left there the original file, luckily > LyX saved my day" :) > > > I vote for 2 (in case users get a vote). > > Then, I think you will like the env var approach that lets you live > as dangerously as you like :) he would write 3 in that case, its almost the same ;) there are two distinct points to be distinguished: 1. to allow users to be where they want - either on the safe side or on the danger side. both your patches satisfy this. 2. to setup the implicit behaviour, when the user didn't choose anything. i think nobody has problem with 1. both opinions on point 2. have their up and downs, from what i distilled: args from the safety side: - you can lost some data args from the danger side: - the real complaint we ever got is fixed, by "main". the exports to .tex and .lyx can happen but they seem to be fabricated just for this discussion. - we break compatility for launching lyx in batch jobs. part of it is repaired by proposed patches. since Juergen gave red flag for 1.6.7, we are lost anyway, thats why i'm not so vocal anymore :) - its pretty standard that linux command line tools are on the danger side by default even when they allow globbing etc... feel free to add points on safe side ;) pavel
Re: Branch regression?
Pavel Sanda wrote: > Juergen, status file for 1.6.7 does not clearly warns about the issue, > you maybe want at least put some note about commandline incompatibility > into web annoucement. I think this can go into the wiki version of the RELEASE_NOTES. Jürgen
Re: Branch regression?
On Wed, Jul 14, 2010 at 12:38:41PM -0400, Julien Rioux wrote: > > Note that cp also has a -n (don't overwrite) flag. This seems pretty > pointless for a cp command, no? Imagine if this was the default > behavior. "cp /path/file.tex ." does nothing... sounds strange, no? $ lyx -e latex foo.lyx Overwrite file? The file ~/foo.tex already exists. Do you want to overwrite that file? Assuming answer is file Overwrite export I don't think that fits the description "does nothing". > I understand that overwriting other files such as eps files during > latex export is an important issue, but it is a different issue. > Anyway I am fine with the environment variable solution, but I would > vote for a -safe or -f=none switch and the default would be -f-main. Well, I think that is a matter of philosophical approach. I think that having to do something for causing damage is better than having to do something for avoiding damage. -- Enrico
Re: Branch regression?
On Wed, Jul 14, 2010 at 06:41:13PM +0200, Pavel Sanda wrote: > Enrico Forestieri wrote: > > On Wed, Jul 14, 2010 at 10:16:19AM -0400, Julien Rioux wrote: > > > It is hard to believe that you would /inadvertently/ use the command > > > line. If you do, then it was your mistake. But wary users could have > > > a shortcut: alias lyx='lyx -f=none' > > > > I think you're missing the point, too. On July 14 you import the .tex > > file. On July 20 you try to export to latex from command line. Export > > fails because you had forgotten that the original file was still there. > > You investigate and say "gosh, I had left there the original file, luckily > > LyX saved my day" :) > > > > > I vote for 2 (in case users get a vote). > > > > Then, I think you will like the env var approach that lets you live > > as dangerously as you like :) > > he would write 3 in that case, its almost the same ;) > > there are two distinct points to be distinguished: > > 1. to allow users to be where they want - either on the safe side or >on the danger side. both your patches satisfy this. > > 2. to setup the implicit behaviour, when the user didn't choose >anything. > > i think nobody has problem with 1. > both opinions on point 2. have their up and downs, from what i distilled: > > args from the safety side: > - you can lost some data > > args from the danger side: > - the real complaint we ever got is fixed, by "main". the exports to .tex > and .lyx can happen but they seem to be fabricated just for this discussion. > - we break compatility for launching lyx in batch jobs. part of it is repaired > by proposed patches. since Juergen gave red flag for 1.6.7, we are lost > anyway, > thats why i'm not so vocal anymore :) > - its pretty standard that linux command line tools are on the danger side by > default > even when they allow globbing etc... > > feel free to add points on safe side ;) I did not imagine I could have caused such a reaction for a safety measure that I thought could have been quite easily overcomed. I am going to do nothing until a *clear* consensus emerges about what should be the default behavior when exporting from command line. I think it boils down to: 1) Never ovewrite files, unless explicitely told so 2) The main file should be always overwritten -- Enrico
Re: Branch regression?
On 14/07/2010 1:10 PM, Enrico Forestieri wrote: On Wed, Jul 14, 2010 at 12:38:41PM -0400, Julien Rioux wrote: Note that cp also has a -n (don't overwrite) flag. This seems pretty pointless for a cp command, no? Imagine if this was the default behavior. "cp /path/file.tex ." does nothing... sounds strange, no? $ lyx -e latex foo.lyx Overwrite file? The file ~/foo.tex already exists. Do you want to overwrite that file? Assuming answer is file Overwrite export I don't think that fits the description "does nothing". I get that message, but lyx proceeds without waiting for my interaction. "Keep file" is assumed. What am I doing wrong? (using ubuntu and latest branch r34829) I understand that overwriting other files such as eps files during latex export is an important issue, but it is a different issue. Anyway I am fine with the environment variable solution, but I would vote for a -safe or -f=none switch and the default would be -f-main. Well, I think that is a matter of philosophical approach. I think that having to do something for causing damage is better than having to do something for avoiding damage. That's why your poll is a good idea. I don't want to flame, I just though you wanted to hear some opinions. My view is, I understand the risks, I still prefer to live dangerously! (and too lazy to change my scripts and makefiles, I guess) Best, Julien
Re: Branch regression?
On Wed, Jul 14, 2010 at 07:47:56PM +0200, Enrico Forestieri wrote:
>
> I did not imagine I could have caused such a reaction for a safety measure
> that I thought could have been quite easily overcomed. I am going to do
> nothing until a *clear* consensus emerges about what should be the default
> behavior when exporting from command line. I think it boils down to:
> 1) Never ovewrite files, unless explicitely told so
> 2) The main file should be always overwritten
Please, find attached the corresponding patches.
- overwrite-1.diff implements behavior 1
- overwrite-2.diff implements behavior 2
The patch obtaining more votes will be applied.
--
Enrico
Index: src/LyX.cpp
===
--- src/LyX.cpp (revisione 34893)
+++ src/LyX.cpp (copia locale)
@@ -736,9 +736,17 @@ bool LyX::init()
if (queryUserLyXDir(package().explicit_user_support()))
reconfigureUserLyXDir();
- // no need for a splash when there is no GUI
if (!use_gui) {
+ // no need for a splash when there is no GUI
first_start = false;
+ // If no -f switch was given, check LYX_FORCE_OVERWRITE
+ if (force_overwrite == NO_FILES) {
+ string const what = getEnv("LYX_FORCE_OVERWRITE");
+ if (what == "all")
+ force_overwrite = ALL_FILES;
+ else if (what == "main")
+ force_overwrite = MAIN_FILE;
+ }
}
// This one is generated in user_support directory by lib/configure.py.
Index: lyx.1in
===
--- lyx.1in (revisione 34893)
+++ lyx.1in (copia locale)
@@ -124,6 +124,17 @@ The user directory is, in order of prece
.B LYX_LOCALEDIR
can be used to tell LyX where to look for the translations of its GUI
strings in other languages.
+
+.TP
+.B LYX_FORCE_OVERWRITE
+can be used to change the default behavior when exporting from command
+line.
+.PP
+By default, LyX does not overwrite files when exporting from command
+line. This behavior can be changed by setting this environment variable,
+which relieves the need of using the \-f switch. Allowed values are either
+"\fBall\fR" or "\fBmain\fR", with same meaning as for the \-f switch.
+If you set this variable, be careful when exporting.
.SH FILES
.nf
.ta \w'\fILIBDIR\fR/lyxrc.in 'u
Index: src/LyX.cpp
===
--- src/LyX.cpp (revisione 34893)
+++ src/LyX.cpp (copia locale)
@@ -93,7 +93,7 @@ bool use_gui = true;
// Tell what files can be silently overwritten during batch export.
// Possible values are: NO_FILES, MAIN_FILE, ALL_FILES.
-OverwriteFiles force_overwrite = NO_FILES;
+OverwriteFiles force_overwrite = MAIN_FILE;
namespace {
@@ -736,9 +736,17 @@ bool LyX::init()
if (queryUserLyXDir(package().explicit_user_support()))
reconfigureUserLyXDir();
- // no need for a splash when there is no GUI
if (!use_gui) {
+ // no need for a splash when there is no GUI
first_start = false;
+ // If no -f switch was given, check LYX_FORCE_OVERWRITE
+ if (force_overwrite == MAIN_FILE) {
+ string const what = getEnv("LYX_FORCE_OVERWRITE");
+ if (what == "all")
+ force_overwrite = ALL_FILES;
+ else if (what == "none")
+ force_overwrite = NO_FILES;
+ }
}
// This one is generated in user_support directory by lib/configure.py.
@@ -1012,9 +1020,9 @@ int parse_help(string const &, string co
" where fmt is the import format of choice\n"
" and file.xxx is the file to be imported.\n"
"\t-f [--force-overwrite] what\n"
- " where what is either `all' or `main'.\n"
- " Using `all', all files are overwritten
during\n"
- " a batch export, otherwise only the main
file will be.\n"
+ " where what is either `all' or `none'.\n"
+ " Using `all', all ancillary files are
overwritten during a\n"
+ " batch export, otherwise none will be (main
file included).\n"
" Anything else is equivalent to `all', but
is not consumed.\n"
"\t-batch execute commands without launching GUI and
exit.\n"
"\t-versionsummarize version and build info\n"
@@ -1123,8 +1131,8 @@ int parse_force(string const & arg, stri
if (arg == "all") {
force_overwrite = ALL_FILES;
Re: Branch regression?
On 07/14/2010 02:47 PM, Enrico Forestieri wrote: On Wed, Jul 14, 2010 at 07:47:56PM +0200, Enrico Forestieri wrote: I did not imagine I could have caused such a reaction for a safety measure that I thought could have been quite easily overcomed. I am going to do nothing until a *clear* consensus emerges about what should be the default behavior when exporting from command line. I think it boils down to: 1) Never ovewrite files, unless explicitely told so 2) The main file should be always overwritten Please, find attached the corresponding patches. - overwrite-1.diff implements behavior 1 - overwrite-2.diff implements behavior 2 The patch obtaining more votes will be applied. I don't have insanely strong views about this, but I tend to agree with Enrico and so would vote for (1). I understand that it will cause some heartache for people who use a lot of scripts, but if the environment variable is checked---is that in this patch?---then it's easy to make one's own system behave globally as if we had gone with (2). That seems good enough to me, and it protects people from doing something dumb. Richard
Re: Branch regression?
Pavel Sanda wrote: hi, some of my script do not work anymore due to the fact that lyx silently fails to overwrite exported files. i vaguely remember introducing -f switch to enforce overwriting, which must be related. in particular commands like: lyx file.lyx -e dvi won't rewrite main file, which shouldn't be... Enrico? http://www.lyx.org/trac/changeset/34533 // Tell what files can be silently overwritten during batch export. // Possible values are: NO_FILES, MAIN_FILE, ALL_FILES. OverwriteFiles force_overwrite = NO_FILES; ... Using `all', all files are overwritten during\n a batch export, otherwise only the main file will be.\n shouldn't be force_overwrite set to MAIN_FILE? this is a showstoppper for anybody using lyx in scripts. pavel
Re: Branch regression?
On Tue, Jul 13, 2010 at 07:39:16PM +0200, Pavel Sanda wrote: Pavel Sanda wrote: hi, some of my script do not work anymore due to the fact that lyx silently fails to overwrite exported files. i vaguely remember introducing -f switch to enforce overwriting, which must be related. in particular commands like: lyx file.lyx -e dvi won't rewrite main file, which shouldn't be... Enrico? http://www.lyx.org/trac/changeset/34533 // Tell what files can be silently overwritten during batch export. // Possible values are: NO_FILES, MAIN_FILE, ALL_FILES. OverwriteFiles force_overwrite = NO_FILES; ... Using `all', all files are overwritten during\n a batch export, otherwise only the main file will be.\n shouldn't be force_overwrite set to MAIN_FILE? No, I wholly agree with http://www.lyx.org/trac/ticket/2762#comment:1 this is a showstoppper for anybody using lyx in scripts. Come on, simply add -f if you don't care overwriting existing files. The way it worked before r34533 was fundamentally wrong. -- Enrico
Re: Branch regression?
Enrico Forestieri wrote: this is a showstoppper for anybody using lyx in scripts. Come on, simply add -f if you don't care overwriting existing files. The way it worked before r34533 was fundamentally wrong. well, changing the semantics of commandline switches is a nightmare. just imagine that each tool you use like grep/sed/sort/ change meaning of the switches from time to time. the scripts become unmaintainable in this way. 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...) i'm sorry coming with this complaint in this phase, but i still think we should keep that -e overwrites the main file. pavel
Re: Branch regression?
On Tue, Jul 13, 2010 at 10:54:07PM +0200, Pavel Sanda wrote: Enrico Forestieri wrote: this is a showstoppper for anybody using lyx in scripts. Come on, simply add -f if you don't care overwriting existing files. The way it worked before r34533 was fundamentally wrong. well, changing the semantics of commandline switches is a nightmare. just imagine that each tool you use like grep/sed/sort/ change meaning of the switches from time to time. the scripts become unmaintainable in this way. 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 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. 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. -- Enrico
Re: Branch regression?
On Tue, Jul 13, 2010 at 07:01:04PM +0200, Pavel Sanda wrote: hi, some of my script do not work anymore due to the fact that lyx silently fails to overwrite exported files. This is rather a trunk regression, as in branch you get notified when the file is not overwritten. -- Enrico
Re: Branch regression?
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
Re: Branch regression?
Enrico Forestieri wrote: some of my script do not work anymore due to the fact that lyx silently fails to overwrite exported files. This is rather a trunk regression, as in branch you get notified when the file is not overwritten. which is not of much help in batch mode pavel
Re: Branch regression?
On Wed, Jul 14, 2010 at 01:10:18AM +0200, Pavel Sanda wrote:
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.
Core of my answer was that switches of commands can be changed (despite
this means breaking scripts) if they are wrong.
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.
Yes, this should have been said more clearly, admittedly.
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.
Neither pdflatex, nor dvips will ever destroy your input file, would they?
Instead, LyX can do that. Try lyx -e lyx foo.lyx and your input file
will be overwritten, updated to the current version and your old input
file is no more.
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.
So, we should check each format in order to decide what to do? If you have
a gun, I suggest that you keep it discharged.
Anyway, would the attached patch be enough for you? When you don't specify
the -f switch, the preference settings are used when exporting from the
command line. However, in order to keep the gun discharged, I added the
none option for -f (I don't like living dangerously).
--
Enrico
Index: src/LyX.cpp
===
--- src/LyX.cpp (revisione 34892)
+++ src/LyX.cpp (copia locale)
@@ -91,9 +91,10 @@ bool use_gui = true;
// Tell what files can be silently overwritten during batch export.
-// Possible values are: NO_FILES, MAIN_FILE, ALL_FILES.
+// Possible values are: NO_FILES, MAIN_FILE, ALL_FILES, USE_RC_PREF.
+// Default is USE_RC_PREF, meaning that the RC preference will be used.
-OverwriteFiles force_overwrite = NO_FILES;
+OverwriteFiles force_overwrite = USE_RC_PREF;
namespace {
@@ -798,6 +799,10 @@ bool LyX::init()
if (!lyxrc.path_prefix.empty())
prependEnvPath(PATH, lyxrc.path_prefix);
+ // If no -f switch was given, inherit the RC pref for overwriting files
+ if (force_overwrite == USE_RC_PREF)
+ force_overwrite = OverwriteFiles(lyxrc.export_overwrite);
+
FileName const document_path(lyxrc.document_path);
if (document_path.exists() document_path.isDirectory())
package().document_dir() = document_path;
@@ -1126,6 +1131,9 @@ int parse_force(string const arg, stri
} else if (arg == main) {
force_overwrite = MAIN_FILE;
return 1;
+ } else if (arg == none) {
+ force_overwrite = NO_FILES;
+ return 1;
}
force_overwrite = ALL_FILES;
return 0;
Index: src/LyX.h
===
--- src/LyX.h (revisione 34892)
+++ src/LyX.h (copia locale)
@@ -37,7 +37,8 @@ class SpellChecker;
enum OverwriteFiles {
NO_FILES,
MAIN_FILE,
- ALL_FILES
+ ALL_FILES,
+ USE_RC_PREF
};
extern bool use_gui;
Re: Branch regression?
On Wed, Jul 14, 2010 at 01:15:52AM +0200, Pavel Sanda wrote: Enrico Forestieri wrote: some of my script do not work anymore due to the fact that lyx silently fails to overwrite exported files. This is rather a trunk regression, as in branch you get notified when the file is not overwritten. which is not of much help in batch mode That was a false alarm. When the old file is identical to the newly produced one, no notification is issued. -- Enrico
Re: Branch regression?
Enrico Forestieri wrote: 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. Neither pdflatex, nor dvips will ever destroy your input file, would they? Instead, LyX can do that. Try lyx -e lyx foo.lyx and your input file will be overwritten, updated to the current version and your old input file is no more. you really mean lyx -e lyx foo.lyx seriously? :) its just pretty normal that if you ask on command line to write output over the input file it gets overwritten like the infamous 'cat file1 file2 file1' mistake. don't see the swith in pdflatex but dvips file.dvi -o file.dvi will of course overwrite input - and thats correct. commands can be changed if they are wrong, but the exotic case invented just for this debate like lyx -e lyx foo.lyx is hardly enough reason. it looks as fixing acrobatic usecases never reported by anybody for the price of introducing new problems. typical usecase is output to dvi/ps/pdf so the question about some real problem our previous scheme causes to users remains (except the fixed issue with overwriting eps figure ;). 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. So, we should check each format in order to decide what to do? If you have a gun, I suggest that you keep it discharged. Anyway, would the attached patch be enough for you? When you don't specify the -f switch, the preference settings are used when exporting from the command line. However, in order to keep the gun discharged, I added the none option for -f (I don't like living dangerously). yes, it would be good enough to keep my mouth shut up. i still maintain that the backward compatibility will cause less user's frustration for this particular switch (ie default RC setting would need to be set on main file overwrite) than new gun-discharged-course but i let the responsibility on Juergen or anybody else who want to comment on :) pavel
Re: Branch regression?
Pavel Sanda wrote: i still maintain that the backward compatibility will cause less user's frustration for this particular switch (ie default RC setting would need to be set on main file overwrite) than new gun-discharged-course but i let the responsibility on Juergen or anybody else who want to comment on :) I don't stop 1.6.7 because of this. Jürgen
Re: Branch regression?
Pavel Sanda wrote: > hi, > > some of my script do not work anymore due to the fact that lyx silently fails > to overwrite exported files. > i vaguely remember introducing -f switch to enforce overwriting, which must > be related. > in particular commands like: > lyx file.lyx -e dvi > won't rewrite main file, which shouldn't be... Enrico? http://www.lyx.org/trac/changeset/34533 // Tell what files can be silently overwritten during batch export. // Possible values are: NO_FILES, MAIN_FILE, ALL_FILES. OverwriteFiles force_overwrite = NO_FILES; ... "Using `all', all files are overwritten during\n" " a batch export, otherwise only the main file will be.\n" shouldn't be force_overwrite set to MAIN_FILE? this is a showstoppper for anybody using lyx in scripts. pavel
Re: Branch regression?
On Tue, Jul 13, 2010 at 07:39:16PM +0200, Pavel Sanda wrote: > Pavel Sanda wrote: > > hi, > > > > some of my script do not work anymore due to the fact that lyx silently > > fails to overwrite exported files. > > i vaguely remember introducing -f switch to enforce overwriting, which must > > be related. > > in particular commands like: > > lyx file.lyx -e dvi > > won't rewrite main file, which shouldn't be... Enrico? > > http://www.lyx.org/trac/changeset/34533 > > // Tell what files can be silently overwritten during batch export. > // Possible values are: NO_FILES, MAIN_FILE, ALL_FILES. > > OverwriteFiles force_overwrite = NO_FILES; > > ... > > "Using `all', all files are overwritten during\n" > " a batch export, otherwise only the main file will be.\n" > > > shouldn't be force_overwrite set to MAIN_FILE? No, I wholly agree with http://www.lyx.org/trac/ticket/2762#comment:1 > this is a showstoppper for anybody using lyx in scripts. Come on, simply add -f if you don't care overwriting existing files. The way it worked before r34533 was fundamentally wrong. -- Enrico
Re: Branch regression?
Enrico Forestieri wrote: > > this is a showstoppper for anybody using lyx in scripts. > > Come on, simply add -f if you don't care overwriting existing files. > The way it worked before r34533 was fundamentally wrong. well, changing the semantics of commandline switches is a nightmare. just imagine that each tool you use like grep/sed/sort/ change meaning of the switches from time to time. the scripts become unmaintainable in this way. 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...) i'm sorry coming with this complaint in this phase, but i still think we should keep that "-e" overwrites the main file. pavel
Re: Branch regression?
On Tue, Jul 13, 2010 at 10:54:07PM +0200, Pavel Sanda wrote: > Enrico Forestieri wrote: > > > this is a showstoppper for anybody using lyx in scripts. > > > > Come on, simply add -f if you don't care overwriting existing files. > > The way it worked before r34533 was fundamentally wrong. > > well, changing the semantics of commandline switches is a nightmare. > > just imagine that each tool you use like grep/sed/sort/ > change meaning of the switches from time to time. the scripts > become unmaintainable in this way. 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 > 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. 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. -- Enrico
Re: Branch regression?
On Tue, Jul 13, 2010 at 07:01:04PM +0200, Pavel Sanda wrote: > hi, > > some of my script do not work anymore due to the fact that lyx > silently fails to overwrite exported files. This is rather a trunk regression, as in branch you get notified when the file is not overwritten. -- Enrico
Re: Branch regression?
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
Re: Branch regression?
Enrico Forestieri wrote: > > some of my script do not work anymore due to the fact that lyx > > silently fails to overwrite exported files. > > This is rather a trunk regression, as in branch you get notified > when the file is not overwritten. which is not of much help in batch mode pavel
Re: Branch regression?
On Wed, Jul 14, 2010 at 01:10:18AM +0200, Pavel Sanda wrote:
>
> 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.
Core of my answer was that switches of commands can be changed (despite
this means breaking scripts) if they are wrong.
> 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.
Yes, this should have been said more clearly, admittedly.
> 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.
Neither pdflatex, nor dvips will ever destroy your input file, would they?
Instead, LyX can do that. Try "lyx -e lyx foo.lyx" and your input file
will be overwritten, updated to the current version and your old input
file is no more.
> 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.
So, we should check each format in order to decide what to do? If you have
a gun, I suggest that you keep it discharged.
Anyway, would the attached patch be enough for you? When you don't specify
the -f switch, the preference settings are used when exporting from the
command line. However, in order to keep the gun discharged, I added the
"none" option for -f (I don't like living dangerously).
--
Enrico
Index: src/LyX.cpp
===
--- src/LyX.cpp (revisione 34892)
+++ src/LyX.cpp (copia locale)
@@ -91,9 +91,10 @@ bool use_gui = true;
// Tell what files can be silently overwritten during batch export.
-// Possible values are: NO_FILES, MAIN_FILE, ALL_FILES.
+// Possible values are: NO_FILES, MAIN_FILE, ALL_FILES, USE_RC_PREF.
+// Default is USE_RC_PREF, meaning that the RC preference will be used.
-OverwriteFiles force_overwrite = NO_FILES;
+OverwriteFiles force_overwrite = USE_RC_PREF;
namespace {
@@ -798,6 +799,10 @@ bool LyX::init()
if (!lyxrc.path_prefix.empty())
prependEnvPath("PATH", lyxrc.path_prefix);
+ // If no -f switch was given, inherit the RC pref for overwriting files
+ if (force_overwrite == USE_RC_PREF)
+ force_overwrite = OverwriteFiles(lyxrc.export_overwrite);
+
FileName const document_path(lyxrc.document_path);
if (document_path.exists() && document_path.isDirectory())
package().document_dir() = document_path;
@@ -1126,6 +1131,9 @@ int parse_force(string const & arg, stri
} else if (arg == "main") {
force_overwrite = MAIN_FILE;
return 1;
+ } else if (arg == "none") {
+ force_overwrite = NO_FILES;
+ return 1;
}
force_overwrite = ALL_FILES;
return 0;
Index: src/LyX.h
===
--- src/LyX.h (revisione 34892)
+++ src/LyX.h (copia locale)
@@ -37,7 +37,8 @@ class SpellChecker;
enum OverwriteFiles {
NO_FILES,
MAIN_FILE,
- ALL_FILES
+ ALL_FILES,
+ USE_RC_PREF
};
extern bool use_gui;
Re: Branch regression?
On Wed, Jul 14, 2010 at 01:15:52AM +0200, Pavel Sanda wrote: > Enrico Forestieri wrote: > > > some of my script do not work anymore due to the fact that lyx > > > silently fails to overwrite exported files. > > > > This is rather a trunk regression, as in branch you get notified > > when the file is not overwritten. > > which is not of much help in batch mode That was a false alarm. When the old file is identical to the newly produced one, no notification is issued. -- Enrico
Re: Branch regression?
Enrico Forestieri wrote: > > 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. > > Neither pdflatex, nor dvips will ever destroy your input file, would they? > Instead, LyX can do that. Try "lyx -e lyx foo.lyx" and your input file > will be overwritten, updated to the current version and your old input > file is no more. you really mean "lyx -e lyx foo.lyx" seriously? :) its just pretty normal that if you ask on command line to write output over the input file it gets overwritten like the infamous 'cat file1 file2 > file1' mistake. don't see the swith in pdflatex but "dvips file.dvi -o file.dvi" will of course overwrite input - and thats correct. commands can be changed if they are wrong, but the exotic case invented just for this debate like "lyx -e lyx foo.lyx" is hardly enough reason. it looks as fixing acrobatic usecases never reported by anybody for the price of introducing new problems. typical usecase is output to dvi/ps/pdf so the question about some real problem our previous scheme causes to users remains (except the fixed issue with overwriting eps figure ;). > > 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. > > So, we should check each format in order to decide what to do? If you have > a gun, I suggest that you keep it discharged. > > Anyway, would the attached patch be enough for you? When you don't specify > the -f switch, the preference settings are used when exporting from the > command line. However, in order to keep the gun discharged, I added the > "none" option for -f (I don't like living dangerously). yes, it would be good enough to keep my mouth shut up. i still maintain that the backward compatibility will cause less user's frustration for this particular switch (ie default RC setting would need to be set on main file overwrite) than new gun-discharged-course but i let the responsibility on Juergen or anybody else who want to comment on :) pavel
Re: Branch regression?
Pavel Sanda wrote: > i still maintain that the backward compatibility will cause less user's > frustration for this particular switch (ie default RC setting would need to > be set on main file overwrite) than new gun-discharged-course but i let > the responsibility on Juergen or anybody else who want to comment on :) I don't stop 1.6.7 because of this. Jürgen
Re: Branch regression
Uwe Stöhr wrote: I fixed this now in trunk and branch (I hope this was OK Jürgen.). I simply forgot to handle OVER and also ATOP in the draw routine. It's OK. Jürgen
Re: Branch regression
Uwe Stöhr wrote: > I fixed this now in trunk and branch (I hope this was OK Jürgen.). I > simply forgot to handle OVER and also ATOP in the draw routine. It's OK. Jürgen
Re: Branch regression
On Mon, May 25, 2009 at 10:30:10PM +0200, Pavel Sanda wrote: 1. new file 2. ctrl+m 3. type \over and spacebar 4. cursor moves out of window, typed characters are not visible The regression was introduced here: http://www.lyx.org/trac/changeset/29263 -- Enrico
Re: Branch regression
On Mon, May 25, 2009 at 11:38:24PM +0200, Enrico Forestieri wrote:
On Mon, May 25, 2009 at 10:30:10PM +0200, Pavel Sanda wrote:
1. new file
2. ctrl+m
3. type \over and spacebar
4. cursor moves out of window, typed characters are not visible
The regression was introduced here:
http://www.lyx.org/trac/changeset/29263
And the attached patch for branch fixes it (also \atop was affected).
--
Enrico
Index: src/mathed/InsetMathFrac.cpp
===
--- src/mathed/InsetMathFrac.cpp(revision 29846)
+++ src/mathed/InsetMathFrac.cpp(working copy)
@@ -218,20 +218,30 @@ void InsetMathFrac::draw(PainterInfo p
ShapeChanger dummy2(pi.base.font, UP_SHAPE);
cell(0).draw(pi, x + 2, y - dim0.des - 5);
cell(1).draw(pi, x + dim0.width() + 5, y + dim1.asc /
2);
- } else if (kind_ == FRAC) {
- cell(0).draw(pi, m - dim0.wid / 2, y - dim0.des - 2 -
5);
- cell(1).draw(pi, m - dim1.wid / 2, y + dim1.asc + 2 -
5);
- } else {
+ } else if (kind_ == CFRAC) {
// \cfrac is always in display size
StyleChanger dummy2(pi.base, LM_ST_DISPLAY);
- if (kind_ == CFRAC)
- cell(0).draw(pi, m - dim0.wid / 2, y - dim0.des
- 2 - 5);
- else if (kind_ == CFRACLEFT)
- cell(0).draw(pi, x + 2, y - dim0.des - 2 - 5);
- else if (kind_ == CFRACRIGHT)
- cell(0).draw(pi, x + dim.wid - dim0.wid - 2,
+ cell(0).draw(pi, m - dim0.wid / 2,
+ y - dim0.des - 2 - 5);
+ cell(1).draw(pi, m - dim1.wid / 2,
+ y + dim1.asc + 2 - 5);
+ } else if (kind_ == CFRACLEFT) {
+ StyleChanger dummy2(pi.base, LM_ST_DISPLAY);
+ cell(0).draw(pi, x + 2, y - dim0.des - 2 - 5);
+ cell(1).draw(pi, m - dim1.wid / 2,
+ y + dim1.asc + 2 - 5);
+ } else if (kind_ == CFRACRIGHT) {
+ StyleChanger dummy2(pi.base, LM_ST_DISPLAY);
+ cell(0).draw(pi, x + dim.wid - dim0.wid - 2,
y - dim0.des - 2 - 5);
- cell(1).draw(pi, m - dim1.wid / 2, y + dim1.asc + 2 -
5);
+ cell(1).draw(pi, m - dim1.wid / 2,
+ y + dim1.asc + 2 - 5);
+ } else {
+ // Classical fraction
+ cell(0).draw(pi, m - dim0.wid / 2,
+ y - dim0.des - 2 - 5);
+ cell(1).draw(pi, m - dim1.wid / 2,
+ y + dim1.asc + 2 - 5);
}
}
if (kind_ == NICEFRAC || kind_ == UNITFRAC) {
@@ -239,13 +249,14 @@ void InsetMathFrac::draw(PainterInfo p
int xx = x;
if (nargs() == 3)
xx += cell(2).dimension(*pi.base.bv).wid + 5;
+
pi.pain.line(xx + dim0.wid,
y + dim.des - 2,
xx + dim0.wid + 5,
y - dim.asc + 2, Color_math);
}
if (kind_ == FRAC || kind_ == CFRAC || kind_ == CFRACLEFT
- || kind_ == CFRACRIGHT || kind_ == OVER)
+ || kind_ == CFRACRIGHT || kind_ == OVER)
pi.pain.line(x + 1, y - 5,
x + dim.wid - 2, y - 5, Color_math);
drawMarkers(pi, x, y);
Re: Branch regression
1. new file 2. ctrl+m 3. type \over and spacebar 4. cursor moves out of window, typed characters are not visible The regression was introduced here: http://www.lyx.org/trac/changeset/29263 I fixed this now in trunk and branch (I hope this was OK Jürgen.). I simply forgot to handle OVER and also ATOP in the draw routine. sorry and regards Uwe
Re: Branch regression
On Mon, May 25, 2009 at 10:30:10PM +0200, Pavel Sanda wrote: > 1. new file > 2. ctrl+m > 3. type "\over" and spacebar > 4. cursor moves out of window, typed characters are not visible The regression was introduced here: http://www.lyx.org/trac/changeset/29263 -- Enrico
Re: Branch regression
On Mon, May 25, 2009 at 11:38:24PM +0200, Enrico Forestieri wrote:
> On Mon, May 25, 2009 at 10:30:10PM +0200, Pavel Sanda wrote:
>
> > 1. new file
> > 2. ctrl+m
> > 3. type "\over" and spacebar
> > 4. cursor moves out of window, typed characters are not visible
>
> The regression was introduced here:
> http://www.lyx.org/trac/changeset/29263
And the attached patch for branch fixes it (also \atop was affected).
--
Enrico
Index: src/mathed/InsetMathFrac.cpp
===
--- src/mathed/InsetMathFrac.cpp(revision 29846)
+++ src/mathed/InsetMathFrac.cpp(working copy)
@@ -218,20 +218,30 @@ void InsetMathFrac::draw(PainterInfo & p
ShapeChanger dummy2(pi.base.font, UP_SHAPE);
cell(0).draw(pi, x + 2, y - dim0.des - 5);
cell(1).draw(pi, x + dim0.width() + 5, y + dim1.asc /
2);
- } else if (kind_ == FRAC) {
- cell(0).draw(pi, m - dim0.wid / 2, y - dim0.des - 2 -
5);
- cell(1).draw(pi, m - dim1.wid / 2, y + dim1.asc + 2 -
5);
- } else {
+ } else if (kind_ == CFRAC) {
// \cfrac is always in display size
StyleChanger dummy2(pi.base, LM_ST_DISPLAY);
- if (kind_ == CFRAC)
- cell(0).draw(pi, m - dim0.wid / 2, y - dim0.des
- 2 - 5);
- else if (kind_ == CFRACLEFT)
- cell(0).draw(pi, x + 2, y - dim0.des - 2 - 5);
- else if (kind_ == CFRACRIGHT)
- cell(0).draw(pi, x + dim.wid - dim0.wid - 2,
+ cell(0).draw(pi, m - dim0.wid / 2,
+ y - dim0.des - 2 - 5);
+ cell(1).draw(pi, m - dim1.wid / 2,
+ y + dim1.asc + 2 - 5);
+ } else if (kind_ == CFRACLEFT) {
+ StyleChanger dummy2(pi.base, LM_ST_DISPLAY);
+ cell(0).draw(pi, x + 2, y - dim0.des - 2 - 5);
+ cell(1).draw(pi, m - dim1.wid / 2,
+ y + dim1.asc + 2 - 5);
+ } else if (kind_ == CFRACRIGHT) {
+ StyleChanger dummy2(pi.base, LM_ST_DISPLAY);
+ cell(0).draw(pi, x + dim.wid - dim0.wid - 2,
y - dim0.des - 2 - 5);
- cell(1).draw(pi, m - dim1.wid / 2, y + dim1.asc + 2 -
5);
+ cell(1).draw(pi, m - dim1.wid / 2,
+ y + dim1.asc + 2 - 5);
+ } else {
+ // Classical fraction
+ cell(0).draw(pi, m - dim0.wid / 2,
+ y - dim0.des - 2 - 5);
+ cell(1).draw(pi, m - dim1.wid / 2,
+ y + dim1.asc + 2 - 5);
}
}
if (kind_ == NICEFRAC || kind_ == UNITFRAC) {
@@ -239,13 +249,14 @@ void InsetMathFrac::draw(PainterInfo & p
int xx = x;
if (nargs() == 3)
xx += cell(2).dimension(*pi.base.bv).wid + 5;
+
pi.pain.line(xx + dim0.wid,
y + dim.des - 2,
xx + dim0.wid + 5,
y - dim.asc + 2, Color_math);
}
if (kind_ == FRAC || kind_ == CFRAC || kind_ == CFRACLEFT
- || kind_ == CFRACRIGHT || kind_ == OVER)
+ || kind_ == CFRACRIGHT || kind_ == OVER)
pi.pain.line(x + 1, y - 5,
x + dim.wid - 2, y - 5, Color_math);
drawMarkers(pi, x, y);
Re: Branch regression
>> 1. new file >> 2. ctrl+m >> 3. type "\over" and spacebar >> 4. cursor moves out of window, typed characters are not visible > > The regression was introduced here: > http://www.lyx.org/trac/changeset/29263 I fixed this now in trunk and branch (I hope this was OK Jürgen.). I simply forgot to handle OVER and also ATOP in the draw routine. sorry and regards Uwe
