Update starttde consistent with the changes made to tdelibs/tdesu/stub.cpp in bug report 766.
The first snippet that is deleted is redundant and conflicts with the same $PATH test several lines later in the script.
The second change ensures $PATH is consistent with stub.cpp, which places $PREFIX/bin in the path order just before /usr/bin and not blindly as first in the search path. If, oddly, /usr/bin is not in the search path then the script falls back to placing $PREFIX/bin first in the search path.
============================================================== diff -urN tdebase/starttde tdebase.new/starttde --- tdebase/starttde 2012-02-15 13:26:30.000000000 -0600 +++ tdebase.new/starttde 2012-02-26 19:08:44.000000000 -0600 @@ -76,15 +76,6 @@ fi fi
-# In case we have been started with full pathname spec without being in PATH. -bindir=`echo "$0" | sed -n 's,^(/.*)/[^/][^/]*$,\1,p'` -if [ -n "$bindir" ]; then - case $PATH in - $bindir|$bindir:*|*:$bindir|*:$bindir:*) ;; - *) PATH=$bindir:$PATH; export PATH;; - esac -fi - # Boot sequence: # # tdeinit is used to fork off processes which improves memory usage @@ -165,7 +156,14 @@ fi if [ -d $TDEDIR/bin ]; then if [ -z "`echo $PATH | grep "$TDEDIR/bin"`" ]; then - export PATH=$TDEDIR/bin:$PATH + # Respect the traditional path order. Don't blindly place $TDEDIR/bin + # first in the path. Only place $TDEDIR/bin before /usr/bin. This order is + # consistent with tdelibs/tdesu/stub.cpp. + if [ -n "`echo $PATH | grep "/usr/bin"`" ]; then + export PATH="`echo $PATH | sed "s|/usr/bin|$TDEDIR/bin:/usr/bin|"`" + else + export PATH=$TDEDIR/bin:$PATH + fi fi fi if [ -d $TDEDIR/share ]; then ==============================================================
I have tested the change. If there are no objections then I would like to push the patch.
Update starttde consistent with the changes made to tdelibs/tdesu/stub.cpp in bug report 766.
The first snippet that is deleted is redundant and conflicts with the same $PATH test several lines later in the script.
The second change ensures $PATH is consistent with stub.cpp, which places $PREFIX/bin in the path order just before /usr/bin and not blindly as first in the search path. If, oddly, /usr/bin is not in the search path then the script falls back to placing $PREFIX/bin first in the search path.
============================================================== diff -urN tdebase/starttde tdebase.new/starttde --- tdebase/starttde 2012-02-15 13:26:30.000000000 -0600 +++ tdebase.new/starttde 2012-02-26 19:08:44.000000000 -0600 @@ -76,15 +76,6 @@ fi fi
-# In case we have been started with full pathname spec without being in PATH. -bindir=`echo "$0" | sed -n 's,^(/.*)/[^/][^/]*$,\1,p'` -if [ -n "$bindir" ]; then
- case $PATH in
- $bindir|$bindir:*|*:$bindir|*:$bindir:*) ;;
- *) PATH=$bindir:$PATH; export PATH;;
- esac
-fi
# Boot sequence: # # tdeinit is used to fork off processes which improves memory usage @@ -165,7 +156,14 @@ fi if [ -d $TDEDIR/bin ]; then if [ -z "`echo $PATH | grep "$TDEDIR/bin"`" ]; then
- export PATH=$TDEDIR/bin:$PATH
- # Respect the traditional path order. Don't blindly place $TDEDIR/bin
- # first in the path. Only place $TDEDIR/bin before /usr/bin. This
order is
- # consistent with tdelibs/tdesu/stub.cpp.
- if [ -n "`echo $PATH | grep "/usr/bin"`" ]; then
export PATH="`echo $PATH | sed"s|/usr/bin|$TDEDIR/bin:/usr/bin|"`"
- else
export PATH=$TDEDIR/bin:$PATH- fi fi
fi if [ -d $TDEDIR/share ]; then ==============================================================
I have tested the change. If there are no objections then I would like to push the patch.
Only concern I have is sed--is sed installed on all systems? Should there be a sanity check for sed somewhere in starttde?
Tim
Only concern I have is sed--is sed installed on all systems? Should there be a sanity check for sed somewhere in starttde?
I don't know. I thought sed was a standard install. Besides there are several other instances of sed being used in the script that precede Trinity. And some sed snippets you added back in the 3.5.11 days. If we add a sed sanity test then the test should be at the beginning of the script and would be beyond the scope of this patch.
Push the patch?
Darrell
Only concern I have is sed--is sed installed on all systems? Should there be a sanity check for sed somewhere in starttde?
I don't know. I thought sed was a standard install. Besides there are several other instances of sed being used in the script that precede Trinity. And some sed snippets you added back in the 3.5.11 days. If we add a sed sanity test then the test should be at the beginning of the script and would be beyond the scope of this patch.
Push the patch?
Darrell
Yes.
Tim
On Mon, Feb 27, 2012 at 5:11 AM, Darrell Anderson humanreadable@yahoo.com wrote:
Update starttde consistent with the changes made to tdelibs/tdesu/stub.cpp in bug report 766.
The first snippet that is deleted is redundant and conflicts with the same $PATH test several lines later in the script.
The second change ensures $PATH is consistent with stub.cpp, which places $PREFIX/bin in the path order just before /usr/bin and not blindly as first in the search path. If, oddly, /usr/bin is not in the search path then the script falls back to placing $PREFIX/bin first in the search path.
============================================================== diff -urN tdebase/starttde tdebase.new/starttde --- tdebase/starttde 2012-02-15 13:26:30.000000000 -0600 +++ tdebase.new/starttde 2012-02-26 19:08:44.000000000 -0600 @@ -76,15 +76,6 @@ fi fi
-# In case we have been started with full pathname spec without being in PATH. -bindir=`echo "$0" | sed -n 's,^(/.*)/[^/][^/]*$,\1,p'` -if [ -n "$bindir" ]; then
- case $PATH in
- $bindir|$bindir:*|*:$bindir|*:$bindir:*) ;;
- *) PATH=$bindir:$PATH; export PATH;;
- esac
-fi
# Boot sequence: # # tdeinit is used to fork off processes which improves memory usage @@ -165,7 +156,14 @@ fi if [ -d $TDEDIR/bin ]; then if [ -z "`echo $PATH | grep "$TDEDIR/bin"`" ]; then
- export PATH=$TDEDIR/bin:$PATH
- # Respect the traditional path order. Don't blindly place $TDEDIR/bin
- # first in the path. Only place $TDEDIR/bin before /usr/bin. This order is
- # consistent with tdelibs/tdesu/stub.cpp.
- if [ -n "`echo $PATH | grep "/usr/bin"`" ]; then
- export PATH="`echo $PATH | sed "s|/usr/bin|$TDEDIR/bin:/usr/bin|"`"
- else
- export PATH=$TDEDIR/bin:$PATH
- fi
fi fi if [ -d $TDEDIR/share ]; then ==============================================================
I have tested the change. If there are no objections then I would like to push the patch.
The patch has bug. Consider $PATH first containing something like '/home/me/opt/usr/bin'. Or even that '/usr/bin_strange_backup'. It must check that '/usr/bin' string is final. That is done with check if it is in begin of string or have ':' in front and it is in end of string or have ':' in back.
I would strongly recommend after renaming such scripts as startkde to create symlinks to old names or at least ask user in postinst to make such links!
On Mon, 27 Feb 2012 10:57:17 +0400 Aleksey Midenkov midenok@gmail.com wrote:
I would strongly recommend after renaming such scripts as startkde to create symlinks to old names or at least ask user in postinst to make such links!
I think a tdesymlinks packages would be a good idea. It would include not only startkde->starttde, but also symlinks to every renamed application such as twin, etc. It would both: -enable former KDE3 users to use the old names, just by installing one package -if the renaming is completed, enable new Trinity users to install it in /usr alongside KDE SC 4/5.
On Mon, Feb 27, 2012 at 12:45 PM, /dev/ammo42 mickeytintincolle@yahoo.fr wrote:
On Mon, 27 Feb 2012 10:57:17 +0400 Aleksey Midenkov midenok@gmail.com wrote:
I would strongly recommend after renaming such scripts as startkde to create symlinks to old names or at least ask user in postinst to make such links!
I think a tdesymlinks packages would be a good idea. It would include not only startkde->starttde, but also symlinks to every renamed application such as twin, etc. It would both: -enable former KDE3 users to use the old names, just by installing one package -if the renaming is completed, enable new Trinity users to install it in /usr alongside KDE SC 4/5.
Making separate package is not necessary and not practical (it must depend on all packages). Better to develop common postinst procedure and include in every such package with info about renamed executables.
On Mon, 27 Feb 2012 14:17:28 +0400 Aleksey Midenkov midenok@gmail.com wrote:
On Mon, Feb 27, 2012 at 12:45 PM, /dev/ammo42 mickeytintincolle@yahoo.fr wrote:
On Mon, 27 Feb 2012 10:57:17 +0400 Aleksey Midenkov midenok@gmail.com wrote:
I would strongly recommend after renaming such scripts as startkde to create symlinks to old names or at least ask user in postinst to make such links!
I think a tdesymlinks packages would be a good idea. It would include not only startkde->starttde, but also symlinks to every renamed application such as twin, etc. It would both: -enable former KDE3 users to use the old names, just by installing one package -if the renaming is completed, enable new Trinity users to install it in /usr alongside KDE SC 4/5.
Making separate package is not necessary and not practical (it must depend on all packages). Better to develop common postinst procedure and include in every such package with info about renamed executables.
Why make the package depend on every Trinity package ? I don't think dangling symlinks are such of a problem. Or perhaps it's just my Slackware-originated "automatic dependencies are too complicated" way of thinking.
On 02/27/2012 02:45 AM, /dev/ammo42 wrote:
I would strongly recommend after renaming such scripts as startkde to
create symlinks to old names or at least ask user in postinst to make such links!
I think a tdesymlinks packages would be a good idea. It would include not only startkde->starttde, but also symlinks to every renamed application such as twin, etc. It would both: -enable former KDE3 users to use the old names, just by installing one package -if the renaming is completed, enable new Trinity users to install it in /usr alongside KDE SC 4/5.
+1,
A symlink packages is a simple fix to a lot of potential problems. By putting symlink control in a single package, you also gain control over the symlink issues that users are bound to create them on their own, and can easily update/revise the symlink setup by updates to a single package. I think it is a good idea. Something like 'tde-tdesymlinks' or 'trinity-tdesymlinks' sounds like a reasonable name.
On Mon, Feb 27, 2012 at 5:53 PM, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 02/27/2012 02:45 AM, /dev/ammo42 wrote:
I would strongly recommend after renaming such scripts as startkde to
create symlinks to old names or at least ask user in postinst to make such links!
I think a tdesymlinks packages would be a good idea. It would include not only startkde->starttde, but also symlinks to every renamed application such as twin, etc. It would both: -enable former KDE3 users to use the old names, just by installing one package -if the renaming is completed, enable new Trinity users to install it in /usr alongside KDE SC 4/5.
+1,
A symlink packages is a simple fix to a lot of potential problems. By putting symlink control in a single package, you also gain control over the symlink issues that users are bound to create them on their own, and can easily update/revise the symlink setup by updates to a single package. I think it is a good idea. Something like 'tde-tdesymlinks' or 'trinity-tdesymlinks' sounds like a reasonable name.
I suppose, it's not that so. From development p.o.v. you are forcing yourself to constantly sync different projects. From user p.o.v. he is forced to install all packages 'tde-tdesymlinks' depends on. Better is to develop common measure for packaging and inform user once (remembering his choice).
On 02/27/2012 09:11 AM, Aleksey Midenkov wrote:
I suppose, it's not that so. From development p.o.v. you are forcing yourself to constantly sync different projects. From user p.o.v. he is forced to install all packages 'tde-tdesymlinks' depends on. Better is to develop common measure for packaging and inform user once (remembering his choice).
I agree. You would need to base the package of symlinks on the user's install preference. Couldn't you use $TDEDIR to obtain the install location and then set the symlinks based on that?
On 27 February 2012 10:44, David C. Rankin drankinatty@suddenlinkmail.comwrote:
On 02/27/2012 09:11 AM, Aleksey Midenkov wrote:
I suppose, it's not that so. From development p.o.v. you are forcing yourself to constantly sync different projects. From user p.o.v. he is forced to install all packages 'tde-tdesymlinks' depends on. Better is to develop common measure for packaging and inform user once (remembering his choice).
I agree. You would need to base the package of symlinks on the user's install preference. Couldn't you use $TDEDIR to obtain the install location and then set the symlinks based on that?
-- David C. Rankin, J.D.,P.E.
Here is a solution.
Don't offer symlinks. Force users to memorize very minor changes in a few differnet programs. If their scripts don't work - it will be pretty obvious why. In our release announcement we will not what has changed.
One thing that bugs me about Trinity is the fear of any change whatsoever. Yes we want to continue the KDE3 tradition, no we are not exactly kde3. If we make changes, users will have to adjust.
It is better to force them to learn the new names then down the road having more nasty issues with symlinks and packaging and a whole mess of crap that isn't a good idea.
Calvin
On Mon, 27 Feb 2012 10:59:08 -0500 Calvin Morrison mutantturkey@gmail.com wrote:
On 27 February 2012 10:44, David C. Rankin drankinatty@suddenlinkmail.comwrote:
On 02/27/2012 09:11 AM, Aleksey Midenkov wrote:
I suppose, it's not that so. From development p.o.v. you are forcing yourself to constantly sync different projects. From user p.o.v. he is forced to install all packages 'tde-tdesymlinks' depends on. Better is to develop common measure for packaging and inform user once (remembering his choice).
I agree. You would need to base the package of symlinks on the user's install preference. Couldn't you use $TDEDIR to obtain the install location and then set the symlinks based on that?
-- David C. Rankin, J.D.,P.E.
Here is a solution.
Don't offer symlinks. Force users to memorize very minor changes in a few differnet programs. If their scripts don't work - it will be pretty obvious why. In our release announcement we will not what has changed.
One thing that bugs me about Trinity is the fear of any change whatsoever. Yes we want to continue the KDE3 tradition, no we are not exactly kde3. If we make changes, users will have to adjust.
It is better to force them to learn the new names then down the road having more nasty issues with symlinks and packaging and a whole mess of crap that isn't a good idea.
I know I'm probably trolling, but I'm not sure making Trinity more difficult to use than KDE SC 4 for former KDE 3 users is a good idea either.
Calvin
On 02/27/2012 09:59 AM, Calvin Morrison wrote:
Here is a solution.
Don't offer symlinks. Force users to memorize very minor changes in a few differnet programs. If their scripts don't work - it will be pretty obvious why. In our release announcement we will not what has changed.
One thing that bugs me about Trinity is the fear of any change whatsoever. Yes we want to continue the KDE3 tradition, no we are not exactly kde3. If we make changes, users will have to adjust.
It is better to force them to learn the new names then down the road having more nasty issues with symlinks and packaging and a whole mess of crap that isn't a good idea.
Calvin
I'm not adverse to change -- I have fully embraced kde4....
Seriously,
The issue isn't 'change' -- it's about 'smart change'. The symlink issue is a crutch - yes, but it is a necessary one until the entire codebase and applications can be updated to use the new names.
CASE-IN-POINT - twin-style-crystal will not build because the ${TDEDIR}/lib/kde directory has been renamed ${TDEDIR}/lib/trinity. With the complex build wizardry now used in building (libtools/cmake/take your pick) it is not a simple 'grep some-changed-name some-source.c' to find the hardcoded link. The problem may not even be in the source, but instead, some crazy submodule somewhere...
If symlinks will provide a way to alleviate build or runtime issues until the source and build system can be completely verified and fixed to use the renamed files/locations, then I think they server a valid temporary purpose.
Just my .02 and not an argument against changing anything.
I would strongly recommend after renaming such scripts as startkde to create symlinks to old names or at least ask user in postinst to make such links!
I'm not in favor of that kind of complicated layer. Change is a part of free/libre software.
The starttde script is a secondary layer in the session startup process that users don't really see. The xinitrc and Xsession scripts handle starttde. Of all the renaming, the only ones I think might trip a few people are tdesu and tdm.
I prefer a "What is New" notice that appears on the desktop with any first Trinity session. Possibly as a pseudo desktop device like some of the other newer desktop device icons.
Let's instead focus on the bug list backlog.
Darrell
On Mon, Feb 27, 2012 at 3:30 PM, Darrell Anderson humanreadable@yahoo.com wrote:
I would strongly recommend after renaming such scripts as startkde to create symlinks to old names or at least ask user in postinst to make such links!
I'm not in favor of that kind of complicated layer. Change is a part of free/libre software.
The starttde script is a secondary layer in the session startup process that users don't really see. The xinitrc and Xsession scripts handle starttde. Of all the renaming, the only ones I think might trip a few people are tdesu and tdm.
Not at all. Any scripts can be utilized by the user (or by the third party) in his own scripts. You'll end up with bug reports like 'My desktop won't start'. That is the least part of the problem. The worse part is that you put user into uncertain state when his environment is not starting and he must debug it for himself. Seems 'a bit' unfriendly.
About that bug what exactly is incomprehensible? I will compose regex later if I'll want to (if you'll not want to fix it) or at least submit bug report.
About that bug what exactly is incomprehensible? I will compose regex later if I'll want to (if you'll not want to fix it) or at least submit bug report.
Comprehension is not the issue. I don't read minds and guessing wastes time.
Please provide an improved sed string. Just don't blurt out there is a bug and not offer a proposed solution --- especially when you have the skills to do so.
Who uses weird directory names like /home/me/opt/usr/bin or /usr/bin_strange_backup?
Darrell
On Mon, Feb 27, 2012 at 7:35 PM, Darrell Anderson humanreadable@yahoo.com wrote:
About that bug what exactly is incomprehensible? I will compose regex later if I'll want to (if you'll not want to fix it) or at least submit bug report.
Comprehension is not the issue. I don't read minds and guessing wastes time.
Please provide an improved sed string. Just don't blurt out there is a bug and not offer a proposed solution --- especially when you have the skills to do so.
Yes, I have. But not have much time. I use my time in my own way, that I'm interested in. It's your mistake by the way. If you have not enough skills then you should be keen to be better and be thankful if someone did spent his time to give you advice. At least, I would do exactly this, but not demand finished solution.
Who uses weird directory names like /home/me/opt/usr/bin or /usr/bin_strange_backup?
Wrong question. In real world if there is a possibility for a bug to happen, it will happen. Though /home/me/some_product/opt/usr/bin is very realistic example.
On Mon, Feb 27, 2012 at 9:23 PM, Darrell Anderson humanreadable@yahoo.com wrote:
Yes, I have. But not have much time. I use my time in my own way, that I'm interested in.
Thank you for letting us know where you stand in this community.
I did my best to help you. Sorry if I can't do more.
On Mon, Feb 27, 2012 at 9:23 PM, Darrell Anderson humanreadable@yahoo.com wrote:
Yes, I have. But not have much time. I use my time in my own way, that I'm interested in.
Thank you for letting us know where you stand in this community.
I did my best to help you. Sorry if I can't do more.
No problem. We all appreciate what you have done so far. :-)
Tim
On Mon, Feb 27, 2012 at 7:35 PM, Darrell Anderson humanreadable@yahoo.com wrote:
About that bug what exactly is incomprehensible? I will compose regex later if I'll want to (if you'll not want to fix it) or at least submit bug report.
Comprehension is not the issue. I don't read minds and guessing wastes time.
Please provide an improved sed string. Just don't blurt out there is a bug and not offer a proposed solution --- especially when you have the skills to do so.
Yes, I have. But not have much time. I use my time in my own way, that I'm interested in. It's your mistake by the way. If you have not enough skills then you should be keen to be better and be thankful if someone did spent his time to give you advice. At least, I would do exactly this, but not demand finished solution.
Who uses weird directory names like /home/me/opt/usr/bin or /usr/bin_strange_backup?
Wrong question. In real world if there is a possibility for a bug to happen, it will happen. Though /home/me/some_product/opt/usr/bin is very realistic example.
This is correct. We need to be careful of corner cases in general.
Tim
The patch has bug. Consider $PATH first containing something like '/home/me/opt/usr/bin'. Or even that '/usr/bin_strange_backup'. It must check that '/usr/bin' string is final. That is done with check if it is in begin of string or have ':' in front and it is in end of string or have ':' in back.
Fix the patch to show me exactly what you want.
Darrell
-
/dev/ammo42 -
Aleksey Midenkov -
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Timothy Pearson