Chris Koeritz [Wed, 10 Jun 2020 19:33:50 +0000 (15:33 -0400)]
cleaner implementation of keep_awake
will still put process in background, but now you can control it from the shell.
unfortunately, these will probably still zombie out if the connection gets dropped for some reason (either because we're not printing frequently enough or for causes out of our control).
Chris Koeritz [Wed, 10 Jun 2020 19:33:50 +0000 (15:33 -0400)]
cleaner implementation of keep_awake
will still put process in background, but now you can control it from the shell.
unfortunately, these will probably still zombie out if the connection gets dropped for some reason (either because we're not printing frequently enough or for causes out of our control).
Chris Koeritz [Mon, 1 Jun 2020 21:02:20 +0000 (17:02 -0400)]
settled on whichable func over direct call to which
the whichable function does the which but also hides errors from not finding the command in question. this is much preferred over seeing errors about "gvim not found" etc.
Chris Koeritz [Mon, 1 Jun 2020 21:02:20 +0000 (17:02 -0400)]
settled on whichable func over direct call to which
the whichable function does the which but also hides errors from not finding the command in question. this is much preferred over seeing errors about "gvim not found" etc.
Chris Koeritz [Mon, 1 Jun 2020 14:19:23 +0000 (10:19 -0400)]
simplified sudo function
tossed out a lot of my changes after discovering the -i option to sudo, which starts a legitimate fresh shell of the type i needed. now, the only weirdity i have to deal with is that the PATH variable still seems to be passed in from sudo even though i've asked for that fresh shell. setting it to null prior to doing the sudo fixes that. works a bit better now.
Chris Koeritz [Mon, 1 Jun 2020 14:19:23 +0000 (10:19 -0400)]
simplified sudo function
tossed out a lot of my changes after discovering the -i option to sudo, which starts a legitimate fresh shell of the type i needed. now, the only weirdity i have to deal with is that the PATH variable still seems to be passed in from sudo even though i've asked for that fresh shell. setting it to null prior to doing the sudo fixes that. works a bit better now.
Chris Koeritz [Wed, 27 May 2020 16:19:06 +0000 (12:19 -0400)]
moved to trusted x.org forwarding
need trusted mode on most of my connections; just don't connect to some random place that you don't trust over ssh, and you won't get a bunch of freaky windows popped on your screen.
Chris Koeritz [Wed, 27 May 2020 16:19:06 +0000 (12:19 -0400)]
moved to trusted x.org forwarding
need trusted mode on most of my connections; just don't connect to some random place that you don't trust over ssh, and you won't get a bunch of freaky windows popped on your screen.
Chris Koeritz [Wed, 27 May 2020 13:43:05 +0000 (09:43 -0400)]
fully functional death star
or, not so much. fixed sudo and resolved the weird mac issue for extract_current_wd or whatever function.
added the mac bash init into the bashrc templates used by the connect feisty script.
this is now working right again on all platforms, i think, although it is probably not yet clobbering every user specific environment variable. soon though.
Chris Koeritz [Wed, 27 May 2020 13:43:05 +0000 (09:43 -0400)]
fully functional death star
or, not so much. fixed sudo and resolved the weird mac issue for extract_current_wd or whatever function.
added the mac bash init into the bashrc templates used by the connect feisty script.
this is now working right again on all platforms, i think, although it is probably not yet clobbering every user specific environment variable. soon though.
Chris Koeritz [Wed, 27 May 2020 03:05:46 +0000 (23:05 -0400)]
vital fixes to sudo function
not sure the initial thrust is done yet, of having root not get a pile of wrong feisty meow variables when i sudo to it with -E flag, but this does at least get the shell options to not still expand for the one case we need. we will fix that to be more specific to enable mac to participate, since mac does actually need aliases expanded.
this also crucially fixes the IMPORTED_XAUTH variable which may never have been working right before? saw a multi-line answer on my host, so taking just the first line of output. not sure that's right yet, but we can't have multiple lines when we add the things in xauth the way we do it now.
Chris Koeritz [Wed, 27 May 2020 03:05:46 +0000 (23:05 -0400)]
vital fixes to sudo function
not sure the initial thrust is done yet, of having root not get a pile of wrong feisty meow variables when i sudo to it with -E flag, but this does at least get the shell options to not still expand for the one case we need. we will fix that to be more specific to enable mac to participate, since mac does actually need aliases expanded.
this also crucially fixes the IMPORTED_XAUTH variable which may never have been working right before? saw a multi-line answer on my host, so taking just the first line of output. not sure that's right yet, but we can't have multiple lines when we add the things in xauth the way we do it now.
Chris Koeritz [Tue, 26 May 2020 20:50:36 +0000 (16:50 -0400)]
getting prepped for better sudo script
these changes pave the way for sudo to seamlessly inherit *most* of the
environment of the user without leaving scads of feisty meow junk or user
specific stuff behind.
Chris Koeritz [Tue, 26 May 2020 20:50:36 +0000 (16:50 -0400)]
getting prepped for better sudo script
these changes pave the way for sudo to seamlessly inherit *most* of the
environment of the user without leaving scads of feisty meow junk or user
specific stuff behind.
projects / feisty_meow.git / log