**** BEGIN LOGGING AT Tue Jan 23 03:00:03 2018 Jan 23 06:21:39 f/sb end Jan 23 06:22:18 ? Jan 23 15:32:04 ~lf Jan 23 15:32:04 methinks #maemo lazyflashing is http://wiki.maemo.org/Updating_the_tablet_firmware#The_Lazy_Approach Jan 23 15:33:56 hi #maemo Jan 23 15:47:38 mreow~ Jan 23 18:29:02 does maemo have something like windows "enviroment variables"? So i could call my scripts from mmc easily. Jan 23 18:33:03 Vajb: s/maemo/Linux/ Jan 23 18:33:04 :) Jan 23 18:33:09 answer, yes Jan 23 18:46:26 great! Jan 23 22:43:43 Vajb: in xterm or ssh try "set" Jan 23 22:43:56 or maybe better "set|less" Jan 23 22:47:05 also try man bash|less -j9 +"/A variable may be assigned to" Jan 23 22:47:43 there yiou got a few screenfull of stuff to read about env vars Jan 23 22:51:30 unlike windows, in unix a var has a scope only of the current process (shell) and all child spawned by that process. So a usual way to define env vars is to place them into an init script. A child can NOT change values of variables in sibling or parent processes (unlike windows where all vars are system global) Jan 23 22:53:19 extually you even might need to "export MyVar" to make it available to child processes Jan 23 22:53:24 actually* Jan 23 22:57:29 an easy to memorize metaphor is: unix hands down info written into the family Bible and its copies from parent to children. The parents never get to know what the children write (or delete or change) in the Bible. On and on from generation to generation. In contrast to that windows has the env vars written to the chalk board in the classroom and every pupil and the teacher can see what every other person writes, changes or deletes there Jan 23 22:58:37 HTH Jan 23 23:02:20 less ~/.profile ~/.bashrc Jan 23 23:07:14 also see /etc/init.d/* - PID1 (the very first process and thus parent of all) runs init scripts to start other processes like X11, so an env var defined in that e.g. X11 initscript will be available and visible to X11 process and all its children Jan 23 23:33:21 So unix is like a religion and Windows is like modern science. Jan 24 00:36:12 DocScrutinizer05 I think that you're not right regarding windows. Windows is a system that inherits DOS. Since DOS, it's possible to add env. variables with "set" commands. So, these variables are set in the current shell, and get inherited by child processes. Also, the "root" environment variables can be set in autoexec.bat. This is a gobal env. variables for a "root" shell. DOS had child processes to, and they inherit the environment of the parent Jan 24 00:36:12 . The same is in windows. Parent cannot get its child's environment. But what windows adds is a possibility to redefine a "root" environment (in settings of "My computer" icon). So that, the global environment change takes effect in all process hierarchy, immediately, i.e, without a reboot. So, the intent is to do that without a reboot. Otherwise, it is done the same way as in UNIX. The only difference is the absence of "export" command, but that's Jan 24 00:36:12 because of a different shell. Jan 24 00:37:46 valerius: you might be right, i'm no windows expert Jan 24 00:38:07 autoexec.bat can be thought of as "init scripts" in DOS Jan 24 00:38:18 DocScrutinizer05 me too :) Jan 24 00:38:44 I'm just pretty sure windows allows global changing of env vars and I know the better half od details how unix works Jan 24 00:41:00 I never meant to claim parent could get childs env, what I meant was child can't change parent's env Jan 24 00:41:20 in unix, and it can in windows Jan 24 00:43:35 I mean I seem to recall in windos you can start an editor of sorts (-> it's a child) to edit global env vars (so owned by (grand)parent) Jan 24 00:43:44 I doubt that. You can only change the root environment with "My Computer" icon. Simple windows processes can't do that. I'm not sure, of course, if a windows program can call an API changing the "root" environment. Maybe, it could, but I cannot tell for sure Jan 24 00:44:32 I'm not a windows expert too :) Jan 24 00:44:48 well, HOW do you change that? you need a process for doing that and that process is... a child of the process defining the vars, no? Jan 24 00:45:50 or maybe not even that Jan 24 00:46:02 hm, not sure. Maybe that requires special privileges, and only "explorer" could do that Jan 24 00:46:23 that's irrelevant for the general architecture Jan 24 00:46:55 * valerius needs to ask about that on #reactos ;) Jan 24 00:47:07 meh, anyway I'm really not the one to disczuss windows idiosyncrasies with Jan 24 00:47:27 :) Jan 24 00:48:08 I just tried to give some reference where unix might surprise users that are familiar with the way windows works, the topic was unix env vars though Jan 24 00:48:52 and you define unix env vars in parent and children inherit a copy basically Jan 24 00:49:16 children never gave write access to parrent address space Jan 24 00:49:31 have* - for (env) vars Jan 24 00:50:06 Yes, the question was about the UNIX environment, I agree. But DOS and DOS-based OS'es took this idea from UNIX, so they work the same Jan 24 00:50:11 parent and child can share a memory segment, env vars are not in such shared segment though Jan 24 00:51:20 yes, that's logical Jan 24 00:52:42 i think "man fork" and/or "man execve" might have details how parent copies env vars into child's address space Jan 24 00:54:57 and for a windows user it might be puzzling to not find a whatchacalledit... "root environment with "My Computer" icon" to change env vars Jan 24 00:55:08 in unix Jan 24 00:59:49 yes, agree Jan 24 01:04:29 >>The fork() function shall create a new process. The new process (child process) shall be an exact copy of the calling process (parent process) except as detailed below: ... [no env vars mentioned in there, so they are a copy] ...<< Jan 24 01:04:48 from man 3p fork Jan 24 01:08:13 well, that's also a pathetic rationale by me, env vars could get stored in any memory range that's world r/w and processes copy pointers to that memory (which is prolly what windows does) Jan 24 01:08:39 anyway in unix they are not stored in such public place Jan 24 01:16:49 Hm, env vars are intended to be copied from parent environment to the child's one. I doubt that they are stored in a public place. I did not thoght it might be too bad in windows. I only thought that the "explorer" process only changes the environment of the whole win32 subsytem, and the changes are then propagated along the process hierarchy (i.e, it's copied down the hierarchy, but not that each process accesses some globally accessible area. That Jan 24 01:16:49 would be too bad even for M$ :)) Jan 24 01:19:55 how are arbitrary processes downstream the explorer hierarchy (read: children of explorer)? Jan 24 01:20:22 but honestly, this is sort of OT for maemo Jan 24 01:25:18 Presumably when getting explorer to start a new program, the new process will have a copy of explorers environment, with changes specified by configuration like global variables and variables set in the shortcut, if relevant. Jan 24 01:25:23 DocScrutinizer05 The global environment is somewhere in a "win32" subsystem. Explorer is just a windows task that could configure the whole subsystem settings, including the environment. Maybe, it's changing only its own environment, and that's sufficient, because it starts all other user processes. So, it can be thought as a login shell. So, it could change it's own environment. I'm not sure, how it's gets propagated to all children. Jan 24 01:25:36 explorer's* Jan 24 01:26:40 Maxdamantus Yes, maybe env changes are propagated only to newly-stared processes, but not the old ones Jan 24 01:29:01 *started Jan 24 01:29:44 I think the general expectation would be that most programs are started through explorer anyway. Jan 24 01:30:30 unix-like systems don't really have that expectation; if someone starts a program from bash, bash directly forks/execs that program. Jan 24 01:30:45 instead of sending some message to the init system to start it. Jan 24 01:32:00 and if you start it from a file manager, the file manager probably forks/execs .. if you start it from some menubar program, that probably forks/execs, etc Jan 24 01:32:45 (not that I use file managers or menubars, so might be mistaken as to how they're likely to work) Jan 24 01:37:21 Maxdamantus hm, I tried to start Far manager in windows, then change the global environment, and then run a compiler from inside Far. It seems, the environment change took an effect in Far's children too, though they are not started directly by explorer. But I'm not sure. Jan 24 01:37:48 Yes, we have gone into offtopic, I agree ;) Jan 24 01:38:29 Yeah, so I'm wondering if such programs will communicate with explorer to get it to start the program instead of directly calling `SpawnProcess` itself. Jan 24 01:44:00 Actually, that's probably not right. Jan 24 01:44:04 Anyway, new programs are started by the win32 sybsystem by parent's request. So, explorer could ask the subsystem to change its global environment, so that all programs started get new environment changes from the central place. No matter, which process starts a child. It still needs to call an API from the win32 subsys. So, the sybsys copies env. variables from the parent's environment to child's one, and adds some new global vars from the global Jan 24 01:44:04 environment. So, it just concats the changed global env to theparent's one. Then no env inheritance violation at all Jan 24 01:44:21 Since I vaguely remember being able to do things like start explorer from the task manager. Jan 24 01:44:57 they are communicating, but not with explorer. They communicate with win32 subsystem, I think Jan 24 01:45:50 yes, task manager can restart explorer -- it seems to be higher in the process hierarchy **** ENDING LOGGING AT Wed Jan 24 03:00:01 2018