In my patched startkde script (bug report 675) I include code to automatically migrate a user's existing KDE3 profile directory.
I'm thinking perhaps I move that code to a separate script, say $PREFIX/bin/migratekde3, and source that script in startkde.
That would allow admins and users to run the script as they please and separate maintenance for us. By moving to a separate script we all can test more easily and improve that script without directly impacting startkde. As a separate script testing could be performed in any desktop environment and not just TDE.
Opinions? Yays? Nays?
Darrell
In my patched startkde script (bug report 675) I include code to automatically migrate a user's existing KDE3 profile directory.
I'm thinking perhaps I move that code to a separate script, say $PREFIX/bin/migratekde3, and source that script in startkde.
That would allow admins and users to run the script as they please and separate maintenance for us. By moving to a separate script we all can test more easily and improve that script without directly impacting startkde. As a separate script testing could be performed in any desktop environment and not just TDE.
Opinions? Yays? Nays?
Darrell
Fine by me--starttde is growing quite large and hard to maintain.
Tim
Le 30/11/2011 20:34, Darrell Anderson a écrit :
In my patched startkde script (bug report 675) I include code to automatically migrate a user's existing KDE3 profile directory.
I'm thinking perhaps I move that code to a separate script, say $PREFIX/bin/migratekde3, and source that script in startkde.
That would allow admins and users to run the script as they please and separate maintenance for us. By moving to a separate script we all can test more easily and improve that script without directly impacting startkde. As a separate script testing could be performed in any desktop environment and not just TDE.
Opinions? Yays? Nays?
I think that the folder migration must really be distinct from startkde. And above all, please, please, please, ask the user what he wants before doing such a thing. The best place to such a dialog should be in the setup wizard (and in the control center).
cp -a $HOME/.kde $HOME/.trinity
It's impossible here: if a program runs this without asking me first, there could be no space left on the disk! It would be good to check for space available.
Other users would prefer a clean install.
I think that the folder migration must really be distinct from startkde.
I already split into two scripts. I have not uploaded anything yet. :)
And above all, please, please, please, ask the user what he wants before doing such a thing. The best place to such a dialog should be in the setup wizard (and in the control center).
By the time a user gets into X, the TDE profile already exists one way or another.
cp -a $HOME/.kde $HOME/.trinity
I run five tests on $HOME/.kde because that profile location is used by KDE4. If any of those tests fail then the directory is presumed to be KDE4.
I also look for $HOME/.kde3.
It's impossible here: if a program runs this without asking me first, there could be no space left on the disk! It would be good to check for space available.
Yeah, that is a good idea!
Other users would prefer a clean install.
Those who want a clean install don't run the migration script.
With splitting the scripts the only way to migrate a KDE3 profile is to run the migratekde3 script. Disabling the executable bit (chmod -x) of the migratekde3 script or not installing kills any automated migration.
I have the startkde script running migratekde3 only if migratekde3 exists and is executable.
Getting the script to ask permission to migrate if already in X is a challenge because the user's profile partially exists when KPersonalizer starts. Therefore any migration needs to happen before even an empty $HOME/.trinity exists. Can KDialog commands be used at that point? If not then the only option is xmessage (eew).
Yes, there are wrinkles to press. :)
Darrell
Le 01/12/2011 00:05, Darrell Anderson a écrit :
Getting the script to ask permission to migrate if already in X is a challenge because the user's profile partially exists when KPersonalizer starts. Therefore any migration needs to happen before even an empty $HOME/.trinity exists. Can KDialog commands be used at that point? If not then the only option is xmessage (eew).
Just an idea, I don't know if it's possible: * Start KDE with a temporary KDEHOME (mktemp) * Copy $HOME/.kde to $HOME/.trinity (if desired) * Copy temporary files from $KDEHOME to $HOME/.trinity (if needed) * Set KDEHOME to $HOME/.trinity (or restart KDE, but it isn't elegant)
?
Getting the script to ask permission to migrate if
already in X is a
challenge because the user's profile partially exists
when
KPersonalizer starts. Therefore any migration needs to
happen before
even an empty $HOME/.trinity exists. Can KDialog
commands be used at
that point? If not then the only option is xmessage
(eew).
Just an idea, I don't know if it's possible:
- Start KDE with a temporary KDEHOME (mktemp)
- Copy $HOME/.kde to $HOME/.trinity (if desired)
- Copy temporary files from $KDEHOME to $HOME/.trinity (if
needed)
- Set KDEHOME to $HOME/.trinity (or restart KDE, but it isn't elegant)
To all:
I uploaded the proposed migration script in bug report 705. This is a proposed script.
My ego is not that big. Feel free to improve the script in all ways! I added comments in the areas I know needs improvement right now.
Yet overall the script works wonderfully well here. So we're off to a good start. :)
Darrell
On Thu, Dec 1, 2011 at 3:06 PM, Darrell Anderson humanreadable@yahoo.com wrote:
Getting the script to ask permission to migrate if
already in X is a
challenge because the user's profile partially exists
when
KPersonalizer starts. Therefore any migration needs to
happen before
even an empty $HOME/.trinity exists. Can KDialog
commands be used at
that point? If not then the only option is xmessage
(eew).
Just an idea, I don't know if it's possible:
- Start KDE with a temporary KDEHOME (mktemp)
- Copy $HOME/.kde to $HOME/.trinity (if desired)
- Copy temporary files from $KDEHOME to $HOME/.trinity (if
needed)
- Set KDEHOME to $HOME/.trinity
(or restart KDE, but it isn't elegant)
To all:
I uploaded the proposed migration script in bug report 705. This is a proposed script.
My ego is not that big. Feel free to improve the script in all ways! I added comments in the areas I know needs improvement right now.
Yet overall the script works wonderfully well here. So we're off to a good start. :)
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
You might want to specify /bin/bash instead of /bin/sh. Debian and I think Ubuntu also, use "dash" as default "sh". I was testing your script a little and got a "Bad substitution" error when Wait_For_Response is called. I don't know exactly why but there is info here:
https://wiki.ubuntu.com/DashAsBinSh
After further reading that page, I believe it's the substring expansion in that function that is the problem. Also on that page is mention of a "checkbashisms" script which I found here:
http://sourceforge.net/projects/checkbaskisms/files/2.0.0.2/
I ran that script on your script and got:
possible bashism in migratekde3 line 69 (${foo:3[:1]}): while [ "${response:0:1}" != "Y" ] && [ "${response:0:1}" != "y" ] && [ "${response:0:1}" != "N" ] && [ "${response:0:1}" != "n" ]; do possible bashism in migratekde3 line 74 (read with option other than -r): read -er -n 1 -p "$1 (y/n): " response
-
Christopher J Kleinschmidt -
Darrell Anderson -
Laurent Dard -
Timothy Pearson