Re: AM/PM in Thunderbird -

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
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




[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux