Re: AM/PM in Thunderbird -
'lo poco, On 02/28/14 06:07, Patrick O'Callaghan wrote: I'm glad we seem to agree. on most all. but i am ending this with that. ;-) -- peace out. in a world with out fences, who needs gates. tc.hago. g . -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On Fri, 2014-02-28 at 00:09 +0600, g wrote: > > On 02/27/14 16:24, Patrick O'Callaghan wrote: > > On Thu, 2014-02-27 at 07:36 +0600, g wrote: > >> also, understand that i am not, nor have i intended to infer, that > >> the *exact* same _process_, including the pid, is restarted, only > >> that the *processes* on the task bar are _restarted_. > > > > As long as we agree that "restarted" is not the same as > > "continued", that is exactly the point I'm trying to make. > > i do not recall using word _continued_, nor will i bother to go > back thru my past emails in this thread to see if i did. You didn't. I did. I didn't say you did. > as i stated, it has been along time back when i read about pid > assignment, but one of the things i do recall is that a pid > number is never reissued. Yet again, that's the point I'm vainly trying to make. > > In your earlier posts you appear to say that a change in process > > environment (e.g. caused by modifying an exported Shell variable) > > can affect the behaviour of other processes not descended from it. > > That's the conclusion I draw from your earlier description of > > what's happening in various terminals, but please correct me if > > I've misunderstood. > > not true. just what did i write to cause you to think such? because > i know and well aware of fact that when one shell environment is > running, it maintains that environment until the user does > something to change environment. this is what the *shell* is all > about. Then we agree. Good. > tho i am not wondering what a system change might be able to do. > and, i would think, that it would be something major, like maybe > a device being disabled. Don't know what that means, but no matter. > > My suggestion about listing PIDs is merely to illustrate that by > > ending a KDE session and starting another one you get a different > > set of processes, so environment changes occurring prior to the > > new session will be reflected in the new processes. However if > > instead of ending the session you merely execute a new terminal > > that doesn't inherit from one where you made the change (say by > > clicking on the desktop menu) then the environment of that new > > process will be the unmodified version as seen by the rest of > > the current session. > > if i understand what you saying, that is not totally true. as > stated, if i am in a terminal and i make a change to the > '.bashrc' file, that change will be picked up by any new terminal > that i start, because new terminal shell will read the new > '.bashrc' file and start with that environment. Well it is totally true in a pedantic sense, but you are correct in pointing out the effect of initialization files. They have the desired effect even though strictly the environment is not being inherited from an unrelated process, merely being recreated. > which is something that i should have stated when i first made > post of using ". /.bashrc". > > something that does come to mind is if i have 2 terminals open > and i change '.bashrc' in terminal-a and then switch to > terminal-b and issue an 'sh' command, i believe that the new > shell would/might inherit the environment of the shell i was > already in. but that is something that i would have to try > before i would say that that *is* what would happen. > [yes, i am too lazy to try right now to see. ;-) ] Of course it does. That's what I've been saying all along, and you yourself said it above. > > IOW, if you want an environment change to be seen by the entire > > session, the only practical way to do it is by terminating the > > session and running another one. This is most commonly done by > > logging out and in again. > > which would depend on just what the processes are using. if none > of them are critical to environment, then a restarting of desktop > is not needed. > > but yes, if a process is environment dependent, desktop needs to > be restarted, or just that process needs to be restarted. I'm glad we seem to agree. poc -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On 02/27/14 16:24, Patrick O'Callaghan wrote: On Thu, 2014-02-27 at 07:36 +0600, g wrote: also, understand that i am not, nor have i intended to infer, that the *exact* same _process_, including the pid, is restarted, only that the *processes* on the task bar are _restarted_. As long as we agree that "restarted" is not the same as > "continued", that is exactly the point I'm trying to make. i do not recall using word _continued_, nor will i bother to go back thru my past emails in this thread to see if i did. as i stated, it has been along time back when i read about pid assignment, but one of the things i do recall is that a pid number is never reissued. therefore i doubt that i used the word _continued_. if i did, all i can say is that is something else that 'chemo brain' haunts. :-) In your earlier posts you appear to say that a change in process environment (e.g. caused by modifying an exported Shell variable) can affect the behaviour of other processes not descended from it. That's the conclusion I draw from your earlier description of > what's happening in various terminals, but please correct me if > I've misunderstood. not true. just what did i write to cause you to think such? because i know and well aware of fact that when one shell environment is running, it maintains that environment until the user does something to change environment. this is what the *shell* is all about. tho i am not wondering what a system change might be able to do. and, i would think, that it would be something major, like maybe a device being disabled. My suggestion about listing PIDs is merely to illustrate that by ending a KDE session and starting another one you get a different > set of processes, so environment changes occurring prior to the > new session will be reflected in the new processes. However if > instead of ending the session you merely execute a new terminal > that doesn't inherit from one where you made the change (say by > clicking on the desktop menu) then the environment of that new > process will be the unmodified version as seen by the rest of > the current session. if i understand what you saying, that is not totally true. as stated, if i am in a terminal and i make a change to the '.bashrc' file, that change will be picked up by any new terminal that i start, because new terminal shell will read the new '.bashrc' file and start with that environment. which is something that i should have stated when i first made post of using ". /.bashrc". something that does come to mind is if i have 2 terminals open and i change '.bashrc' in terminal-a and then switch to terminal-b and issue an 'sh' command, i believe that the new shell would/might inherit the environment of the shell i was already in. but that is something that i would have to try before i would say that that *is* what would happen. [yes, i am too lazy to try right now to see. ;-) ] IOW, if you want an environment change to be seen by the entire session, the only practical way to do it is by terminating the session and running another one. This is most commonly done by logging out and in again. which would depend on just what the processes are using. if none of them are critical to environment, then a restarting of desktop is not needed. but yes, if a process is environment dependent, desktop needs to be restarted, or just that process needs to be restarted. -- peace out. in a world with out fences, who needs gates. tc.hago. g . -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On Thu, 2014-02-27 at 07:36 +0600, g wrote: > also, understand that i am not, nor have i intended to infer, > that the *exact* same _process_, including the pid, is restarted, > only that the *processes* on the task bar are _restarted_. As long as we agree that "restarted" is not the same as "continued", that is exactly the point I'm trying to make. In your earlier posts you appear to say that a change in process environment (e.g. caused by modifying an exported Shell variable) can affect the behaviour of other processes not descended from it. That's the conclusion I draw from your earlier description of what's happening in various terminals, but please correct me if I've misunderstood. My suggestion about listing PIDs is merely to illustrate that by ending a KDE session and starting another one you get a different set of processes, so environment changes occurring prior to the new session will be reflected in the new processes. However if instead of ending the session you merely execute a new terminal that doesn't inherit from one where you made the change (say by clicking on the desktop menu) then the environment of that new process will be the unmodified version as seen by the rest of the current session. IOW, if you want an environment change to be seen by the entire session, the only practical way to do it is by terminating the session and running another one. This is most commonly done by logging out and in again. poc -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On 02/27/14 01:53, Patrick O'Callaghan wrote: On Wed, 2014-02-26 at 23:45 +0600, g wrote: <<<>>> bob know what it means. :-) As do I, now that you've said you meant "s/n ratio". granted, due to s/n also abrivs 'serial number'. next time i will use the other abriv - s2n. :-) <<>>> yes, when kde is closed, what ever was running is closed, unless there was a 'nohup' issued. when i _logout_ from kde desktop, to 'switch user', 'suspend to disk', 'suspend to memory', 'restart', or 'shutdown', i do not close out what ever i have sitting open in 'task bar'. Switching user and suspending do not log out. Shutdown and > restart do. ok. i do not use either. next time i will try and not presume. ;-) <<>> Can't think of a reason for that offhand, other than some kind of script bug. 'script bug'? A bug in the .bashrc init script. which? '/etc/bashrc' or '/etc/skel/.bashrc'? i would think it to be former than latter. strange that if it is either, it has not been noticed before now. <<<>>> not all true. see above. I disagree. I invite you to list the process IDs of the running > apps in one of your sessions, close the session without restarting > the system, start a new session, then list the PIDs again. The two > lists will show different PIDs. well now, that is a rather boastful statement to make. even for you. ;-) in fact, i would go so far as to say that a few system processes will have same pid from one start up to another, much less a user starting a desktop having the same numbers. i would say that maybe the 1st 100 or 200 system processes listed _might_ have the same pid, but there will be very few after that. i base this on way pids are assigned, time taken to start processes, time allotted to the processes, and a whole lot of other variables that i do not recall. it has been a long time passed when i first read about pid numbers and how they are assigned to a process. and, i am talking about sometime back in the 80's. just by listing the first 200 lines of different start ups, one will/should very quickly see a difference. and, note that i use word _line_, because the 1st couple hundred lines are not in a sequential order because there are processes that start and end during system start up, as well as with a user start up. also, understand that i am not, nor have i intended to infer, that the *exact* same _process_, including the pid, is restarted, only that the *processes* on the task bar are _restarted_. with two exceptions, "firefox's library" and "thunderbird's address book". they must be restarted manually, which is something that i have noted when restarting desktop. minor things do not remain in my 'chemo brain'. ;-) -- peace out. in a world with out fences, who needs gates. tc.hago. g . -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On Wed, 2014-02-26 at 23:45 +0600, g wrote: > > I've a feeling we're talking at cross purposes, but here goes: > > not sure what you mean by "cross purposes", but, that is ok with > me. ;-) > > >> now that the s/n has dropped, and i have finished playing with > >> '.bashrc', 'alias', and a script file, i submit the following. > > > > Don't know what "s/n" means, but never mind. > > s/n = Signal to Noise ratio. > > bob know what it means. :-) As do I, now that you've said you meant "s/n ratio". > > What do you mean you don't close them? KDE closes them when you > > terminate the session. You'd have to take special measures to > > prevent this and I'm not sure it's even possible to do in a > > sensible way (i.e. retaining some way to access the terminal > > after KDE closes). > > so that you will know, it is possible. > > yes, when kde is closed, what ever was running is closed, unless > there was a 'nohup' issued. > > when i _logout_ from kde desktop, to 'switch user', 'suspend to > disk', 'suspend to memory', 'restart', or 'shutdown', i do not > close out what ever i have sitting open in 'task bar'. Switching user and suspending do not log out. Shutdown and restart do. > ie, open windows "top to bottom": > 4 firefox windows and library, 6 terminals, 4 konqueror windows, > a bash shell started from konqueror, freecell, ksnapshot, system > monitor, 4 kwrite windows, disk utility, system settings, address > book, thunderbird, and wireshark. > > when i logout of kde for any of above reasons, i _do_not_ close any > windows. when i login to kde again, _all_ of above windows are > reopended with out my opening them again. When you logout or restart, you are *not* continuing the same processes. Presumably you have configured the KDE session manager to reopen the same apps as when you left the session. These are new processes which attempt to continue where they left off, but they are being executed from the pristine binaries and will not conserve transitory environment state (unless they are written to do that). > >> in each of the terminals, i have at least 2 tabs open. in each > >> terminal, when in right most tab, everything works fine. for some > >> reason, that i did not bother to figure out why, it does not work > >> in other tabs. > > > > Can't think of a reason for that offhand, other than some kind of > > script bug. > > 'script bug'? A bug in the .bashrc init script. > > To be more precise: if you run KDE from a desktop manager (KDM, > > GDM, whatever) then terminating KDE logs you out. If you run KDE > > by first logging into a terminal and executing startkde then yes, > > you can terminate the KDE session, fiddle with Shell variables, > > then run another KDE session, so strictly speaking you haven't > > logged out and the new KDE session will see the altered > > environment. However any terminals that were running *within* the > > KDE session have been terminated and have to be re-executed (with > > the now current environment) when you re-enter KDE. > > not all true. see above. I disagree. I invite you to list the process IDs of the running apps in one of your sessions, close the session without restarting the system, start a new session, then list the PIDs again. The two lists will show different PIDs. poc -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
hello poco, On 02/26/14 16:43, Patrick O'Callaghan wrote: On Wed, 2014-02-26 at 14:07 +0600, g wrote: <<<>>> <> >> ok, all. I've a feeling we're talking at cross purposes, but here goes: not sure what you mean by "cross purposes", but, that is ok with me. ;-) now that the s/n has dropped, and i have finished playing with '.bashrc', 'alias', and a script file, i submit the following. Don't know what "s/n" means, but never mind. s/n = Signal to Noise ratio. bob know what it means. :-) the command that i suggested is what i use when i am in 'init level 1' to reactivate ".bashrc". i also use it in 'level 3', and 'level 5'. Irrelevant. When a process changes an environment variable and > exports it, it means it's inherited by all descendants of that > process. The various Shells provide a handy syntax for this, but > the principle applies to all processes including init. agreed. i was just stating where i have used '. ~/.bashrc'. when i am at either of those levels and i open a new terminal, if i have made a change to ".bashrc", changes are present, just like they are if i open a new terminal in 'level 3' or in 'level 5'. [i am not dropping down to 'level 1' just to test.] Of course, see above. agree. see above. what i did do, while at 'level 5', is i edited ".bashrc" to add a couple of 'alias' lines, and wrote a script file for alias >> files. while using kde, i ran test of following and it all works as >> noted below. i keep 6 terminals running in kde, i do not close them when i end kde. What do you mean you don't close them? KDE closes them when you terminate the session. You'd have to take special measures to > prevent this and I'm not sure it's even possible to do in a > sensible way (i.e. retaining some way to access the terminal > after KDE closes). so that you will know, it is possible. yes, when kde is closed, what ever was running is closed, unless there was a 'nohup' issued. when i _logout_ from kde desktop, to 'switch user', 'suspend to disk', 'suspend to memory', 'restart', or 'shutdown', i do not close out what ever i have sitting open in 'task bar'. ie, open windows "top to bottom": 4 firefox windows and library, 6 terminals, 4 konqueror windows, a bash shell started from konqueror, freecell, ksnapshot, system monitor, 4 kwrite windows, disk utility, system settings, address book, thunderbird, and wireshark. when i logout of kde for any of above reasons, i _do_not_ close any windows. when i login to kde again, _all_ of above windows are reopended with out my opening them again. in each of the terminals, i have at least 2 tabs open. in each terminal, when in right most tab, everything works fine. for some reason, that i did not bother to figure out why, it does not work in other tabs. Can't think of a reason for that offhand, other than some kind of > script bug. 'script bug'? Each terminal consists of one konsole process and one or more Shells (one per tab). this is true. if i open a new terminal after reactivating '.bashrc' the >> additions are active. Obviously, see above (again). agreed, see above. no logout and login is needed. To be more precise: if you run KDE from a desktop manager (KDM, > GDM, whatever) then terminating KDE logs you out. If you run KDE > by first logging into a terminal and executing startkde then yes, > you can terminate the KDE session, fiddle with Shell variables, > then run another KDE session, so strictly speaking you haven't > logged out and the new KDE session will see the altered > environment. However any terminals that were running *within* the > KDE session have been terminated and have to be re-executed (with > the now current environment) when you re-enter KDE. not all true. see above. _in_addition_: i erred in last post; alias nbrc='. ~/.bashrc' should have read, alias rbrc='. ~/.bashrc' so that script 'nbrc' can be reached. -- peace out. in a world with out fences, who needs gates. tc.hago. g . -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On 24.02.2014 13:43, Bob Goodwin wrote: > > For a long time I have been doing: > > /etc/locale.confchange:LANG="en_US.UTF-8" > > LANG="en_GB.UTF-8" > > To make Thunderbird list messages with 24 hour time. > > Can someone suggest a better way to accomplish this? > > Bob > /usr/bin/thunderbird24h: #!/bin/sh LC_TIME=C export LC_TIME /usr/bin/thunderbird poma -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On Wed, 2014-02-26 at 14:07 +0600, g wrote: > > On 02/25/14 20:52, Patrick O'Callaghan wrote: > > On Tue, Feb 25, 2014 at 12:27 PM, Joachim Backes > > wrote: > >>> That will have absolutely no effect on any currently running program, > >>> including the desktop you're working in. Processes inherit external > >>> variables from the process that executed them, so only those which are > >>> run from the new shell you just entered are going to see the change. > >>> You could of course visit every other running Shell and source > >>> ~/.bashrc, but that will still not affect apps run from the GUI. > >>> > >>> IOW, yes you have to log out and in again. > >> > >> Not necessarily! > >> > >> 1) Finish thunderbird > >> 2) Until the next logout: . ~/.bashrc;thunderbird > >> > >> No logout needed :-) > > > > This is consistent with what I said. You're executing a new instance > > of TB from the Shell you modified with new external variables. > > > > You could also do: > > > > VARIABLE1=value1 VARIABLE2=value2 ... thunderbird > > > > without having to invoke a new Shell. Same effect. > > > > poc > > ok, all. I've a feeling we're talking at cross purposes, but here goes: > now that the s/n has dropped, and i have finished playing with > '.bashrc', 'alias', and a script file, i submit the following. Don't know what "s/n" means, but never mind. > the command that i suggested is what i use when i am in 'init > level 1' to reactivate ".bashrc". i also use it in 'level 3', > and 'level 5'. Irrelevant. When a process changes an environment variable and exports it, it means it's inherited by all descendants of that process. The various Shells provide a handy syntax for this, but the principle applies to all processes including init. > when i am at either of those levels and i open a new terminal, if > i have made a change to ".bashrc", changes are present, just like > they are if i open a new terminal in 'level 3' or in 'level 5'. > [i am not dropping down to 'level 1' just to test.] Of course, see above. > what i did do, while at 'level 5', is i edited ".bashrc" to add > a couple of 'alias' lines, and wrote a script file for alias files. > > while using kde, i ran test of following and it all works as noted > below. > > i keep 6 terminals running in kde, i do not close them when i > end kde. What do you mean you don't close them? KDE closes them when you terminate the session. You'd have to take special measures to prevent this and I'm not sure it's even possible to do in a sensible way (i.e. retaining some way to access the terminal after KDE closes). > in each of the terminals, i have at least 2 tabs open. in each > terminal, when in right most tab, everything works fine. for some > reason, that i did not bother to figure out why, it does not work > in other tabs. Can't think of a reason for that offhand, other than some kind of script bug. Each terminal consists of one konsole process and one or more Shells (one per tab). > if i open a new terminal after reactivating '.bashrc' the additions > are active. Obviously, see above (again). > no logout and login is needed. To be more precise: if you run KDE from a desktop manager (KDM, GDM, whatever) then terminating KDE logs you out. If you run KDE by first logging into a terminal and executing startkde then yes, you can terminate the KDE session, fiddle with Shell variables, then run another KDE session, so strictly speaking you haven't logged out and the new KDE session will see the altered environment. However any terminals that were running *within* the KDE session have been terminated and have to be re-executed (with the now current environment) when you re-enter KDE. poc -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On 02/25/14 20:52, Patrick O'Callaghan wrote: On Tue, Feb 25, 2014 at 12:27 PM, Joachim Backes wrote: That will have absolutely no effect on any currently running program, including the desktop you're working in. Processes inherit external variables from the process that executed them, so only those which are run from the new shell you just entered are going to see the change. You could of course visit every other running Shell and source ~/.bashrc, but that will still not affect apps run from the GUI. IOW, yes you have to log out and in again. Not necessarily! 1) Finish thunderbird 2) Until the next logout: . ~/.bashrc;thunderbird No logout needed :-) This is consistent with what I said. You're executing a new instance of TB from the Shell you modified with new external variables. You could also do: VARIABLE1=value1 VARIABLE2=value2 ... thunderbird without having to invoke a new Shell. Same effect. poc ok, all. now that the s/n has dropped, and i have finished playing with '.bashrc', 'alias', and a script file, i submit the following. the command that i suggested is what i use when i am in 'init level 1' to reactivate ".bashrc". i also use it in 'level 3', and 'level 5'. when i am at either of those levels and i open a new terminal, if i have made a change to ".bashrc", changes are present, just like they are if i open a new terminal in 'level 3' or in 'level 5'. [i am not dropping down to 'level 1' just to test.] what i did do, while at 'level 5', is i edited ".bashrc" to add a couple of 'alias' lines, and wrote a script file for alias files. while using kde, i ran test of following and it all works as noted below. i keep 6 terminals running in kde, i do not close them when i end kde. in each of the terminals, i have at least 2 tabs open. in each terminal, when in right most tab, everything works fine. for some reason, that i did not bother to figure out why, it does not work in other tabs. if i open a new terminal after reactivating '.bashrc' the additions are active. no logout and login is needed. ++ addition to my "~/.bashrc": ## reactivate ~/.bashrc - test for new alias alias nbrc='. ~/.bashrc' alias tst='echo "this is a test"' ++ script file - 'nbrc': #!/bin/sh ## fn=nbrc vr= -0001 ## use=reactivate .bashrc - test for new alias . ~/.bashrc echo "~/.bashrc reactivated" echo alias|sort echo ++ enjoy. ;-) later. i am "pulling the plugs" and crashing. -- peace out. in a world with out fences, who needs gates. tc.hago. g . -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On 02/25/14 03:04, g wrote: > > > On 02/25/14 06:53, Mark LaPierre wrote: >> On 02/24/14 19:31, g wrote: >>> On 02/24/14 19:13, Ed Greshko wrote: On 02/24/14 20:43, Bob Goodwin wrote: > > For a long time I have been doing: > > /etc/locale.confchange:LANG="en_US.UTF-8" > > LANG="en_GB.UTF-8" > > To make Thunderbird list messages with 24 hour time. > > Can someone suggest a better way to accomplish this? > > Bob Add export LC_TIME=C to your .bashrc Of course you'll need to logout/login for this to take effect globally in your GUI >>> >>> instead of taking the time needed to logout and login to desktop, i >>> find that opening a terminal and entering; >>> >>> . ~/.bashrc >>> >>> is a faster way to effect new .bashrc entries. >> >> That's an effective way to make the change active in the current >> shell but that does not make the change effective in your current >> GUI session. >> >> It's good practice to try that before you log off just in case >> you've buggered up your .bashrc bad enough that it won't let you >> log on again after you log off. > > did you try it or are you just guessing? :-) > No guessing is required. Your current GUI is running in the environment it inherited from it's parent shell when it was started. Changes to .bashrc are not retroactive. Children can not alter the parent environment. -- _ °v° /(_)\ ^ ^ Mark LaPierre Registered Linux user No #267004 https://linuxcounter.net/ -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On Tue, Feb 25, 2014 at 12:27 PM, Joachim Backes wrote: >> That will have absolutely no effect on any currently running program, >> including the desktop you're working in. Processes inherit external >> variables from the process that executed them, so only those which are >> run from the new shell you just entered are going to see the change. >> You could of course visit every other running Shell and source >> ~/.bashrc, but that will still not affect apps run from the GUI. >> >> IOW, yes you have to log out and in again. > > Not necessarily! > > 1) Finish thunderbird > 2) Until the next logout: . ~/.bashrc;thunderbird > > No logout needed :-) This is consistent with what I said. You're executing a new instance of TB from the Shell you modified with new external variables. You could also do: VARIABLE1=value1 VARIABLE2=value2 ... thunderbird without having to invoke a new Shell. Same effect. poc -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On 02/25/2014 11:49 AM, Patrick O'Callaghan wrote: > On Tue, Feb 25, 2014 at 12:31 AM, g wrote: >> instead of taking the time needed to logout and login to desktop, >> i find that opening a terminal and entering; >> >>. ~/.bashrc >> >> is a faster way to effect new .bashrc entries. > > That will have absolutely no effect on any currently running program, > including the desktop you're working in. Processes inherit external > variables from the process that executed them, so only those which are > run from the new shell you just entered are going to see the change. > You could of course visit every other running Shell and source > ~/.bashrc, but that will still not affect apps run from the GUI. > > IOW, yes you have to log out and in again. Not necessarily! 1) Finish thunderbird 2) Until the next logout: . ~/.bashrc;thunderbird No logout needed :-) Joachim Backes -- Fedora release 20 (Heisenbug) Kernel-3.13.4-200.fc20.x86_64 Joachim Backes https://www-user.rhrk.uni-kl.de/~backes/de-index.html https://www-user.rhrk.uni-kl.de/~backes/en-index.html -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On Tue, Feb 25, 2014 at 12:31 AM, g wrote: > instead of taking the time needed to logout and login to desktop, > i find that opening a terminal and entering; > >. ~/.bashrc > > is a faster way to effect new .bashrc entries. That will have absolutely no effect on any currently running program, including the desktop you're working in. Processes inherit external variables from the process that executed them, so only those which are run from the new shell you just entered are going to see the change. You could of course visit every other running Shell and source ~/.bashrc, but that will still not affect apps run from the GUI. IOW, yes you have to log out and in again. poc -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On 02/25/14 06:53, Mark LaPierre wrote: On 02/24/14 19:31, g wrote: On 02/24/14 19:13, Ed Greshko wrote: On 02/24/14 20:43, Bob Goodwin wrote: For a long time I have been doing: /etc/locale.confchange:LANG="en_US.UTF-8" LANG="en_GB.UTF-8" To make Thunderbird list messages with 24 hour time. Can someone suggest a better way to accomplish this? Bob Add export LC_TIME=C to your .bashrc Of course you'll need to logout/login for this to take effect globally in your GUI instead of taking the time needed to logout and login to desktop, i find that opening a terminal and entering; . ~/.bashrc is a faster way to effect new .bashrc entries. That's an effective way to make the change active in the current shell but that does not make the change effective in your current > GUI session. It's good practice to try that before you log off just in case you've buggered up your .bashrc bad enough that it won't let you > log on again after you log off. did you try it or are you just guessing? :-) -- peace out. in a world with out fences, who needs gates. tc.hago. g . -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On 02/24/14 19:31, g wrote: > > > On 02/24/14 19:13, Ed Greshko wrote: >> On 02/24/14 20:43, Bob Goodwin wrote: >>> >>> For a long time I have been doing: >>> >>> /etc/locale.confchange:LANG="en_US.UTF-8" >>> >>> LANG="en_GB.UTF-8" >>> >>> To make Thunderbird list messages with 24 hour time. >>> >>> Can someone suggest a better way to accomplish this? >>> >>> Bob >>> >> >> Add >> >> export LC_TIME=C >> >> to your .bashrc >> >> Of course you'll need to logout/login for this to take effect >> globally in your GUI > > instead of taking the time needed to logout and login to desktop, > i find that opening a terminal and entering; > >. ~/.bashrc > > is a faster way to effect new .bashrc entries. > > That's an effective way to make the change active in the current shell but that does not make the change effective in your current GUI session. It's good practice to try that before you log off just in case you've buggered up your .bashrc bad enough that it won't let you log on again after you log off. -- _ °v° /(_)\ ^ ^ Mark LaPierre Registered Linux user No #267004 https://linuxcounter.net/ -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On 02/24/14 19:13, Ed Greshko wrote: On 02/24/14 20:43, Bob Goodwin wrote: For a long time I have been doing: /etc/locale.confchange:LANG="en_US.UTF-8" LANG="en_GB.UTF-8" To make Thunderbird list messages with 24 hour time. Can someone suggest a better way to accomplish this? Bob Add export LC_TIME=C to your .bashrc Of course you'll need to logout/login for this to take effect > globally in your GUI instead of taking the time needed to logout and login to desktop, i find that opening a terminal and entering; . ~/.bashrc is a faster way to effect new .bashrc entries. -- peace out. in a world with out fences, who needs gates. tc.hago. g . -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On 02/24/14 08:13, Ed Greshko wrote: > To make Thunderbird list messages with 24 hour time. > > Can someone suggest a better way to accomplish this? > > Bob > Add export LC_TIME=C to your .bashrc Of course you'll need to logout/login for this to take effect globally in your GUI Thank you Ed. That answers an old question I've had for a long time. Worked as you said it would. Bob -- http://www.qrz.com/db/w2bod Box10 Fedora-20/64bit Linux/XFCE -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: AM/PM in Thunderbird -
On 02/24/14 20:43, Bob Goodwin wrote: > > For a long time I have been doing: > > /etc/locale.confchange:LANG="en_US.UTF-8" > > LANG="en_GB.UTF-8" > > To make Thunderbird list messages with 24 hour time. > > Can someone suggest a better way to accomplish this? > > Bob > Add export LC_TIME=C to your .bashrc Of course you'll need to logout/login for this to take effect globally in your GUI -- Getting tired of non-Fedora discussions and self-serving posts -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
AM/PM in Thunderbird -
For a long time I have been doing: /etc/locale.confchange:LANG="en_US.UTF-8" LANG="en_GB.UTF-8" To make Thunderbird list messages with 24 hour time. Can someone suggest a better way to accomplish this? Bob -- http://www.qrz.com/db/w2bod Box10 Fedora-20/64bit Linux/XFCE -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
