=== thumper is now known as thumper-afk === thumper-afk is now known as thumper [15:41] Morning. [19:24] morning [19:26] morning [19:29] oh kernel update .. be back in a bit === _thumper_ is now known as thumper [22:21] ok, stupid question time [22:22] as user tim on my system I have a PATH defined that includes some local bin directories [22:22] created an exec called "filetest" in one of these "~/go/bin" for those that are interested [22:22] sudo filetest fails with command not found [22:22] but yet [22:22] sudo echo $PATH shows the path as including it [22:23] so why doesn't sudo look in the PATH for the directories? [22:23] I think it is just looking in /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin [22:23] which is what I get if I do: 'sudo su -', 'echo $PATH' [22:23] what happens with 'which filetest' ? [22:24] ibeardslee: locally? or with sudo? [22:24] both [22:24] $ which filetest [22:24] /home/tim/go/bin/filetest [22:24] $ sudo which filetest [22:24] is empty [22:24] because you're using sudo, and you don't have it set to keep PATH [22:25] when you sudo echo $PATH it expands it before passing to sudo [22:25] ah [22:25] that makes sense [22:26] Defaults env_reset [22:26] Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" [22:26] * thumper copies filetest to /usr/local/bin to continue testing [22:26] you could change /etc/sudoers if you want, but that's messy :) [22:26] nah [22:26] doesn't matter for the testing I'm doing [22:27] I'm wanting to confirm some uid checks and hunting for a file [22:28] morning [22:29] thumper: to see the PATH inside sudo, you could try: sudo printenv|grep PATH [22:30] olly: oh, ta [22:30] is printenv like env? [22:30] same thing [22:31] it gives your fingers more exercise [22:31] * olly didn't know env also printed the env - only used it as a shell-portable way to set variables for a command [23:19] I notice that with all the X-Launchpad headers .. there isn't one that says what the bug number is [23:21] ibeardslee: probably considered redundant since the bug # is in the subject [23:22] I'm having some fail at managing to extract that in my .procmailrc [23:22] would probably have just as much trouble if it was part of another header [23:22] what are you wanting to do? [23:23] filter bugs into separate folders per bug [23:23] will evolution's search folders to deal with the other breakdowns as required [23:23] sounds a bit like overkill, but that's because I have too many bugs to see :) [23:24] could get overkill down the track, but I'll worry about it then [23:27] I'm sure you could use a regular expression on the Subject: header to capture the bug # & use that [23:27] yeap .. working on that .. actually using the reply-to header [23:27] ok [23:28] .. but failing [23:28] ibeardslee: we don't normally have people wanting to filter on individual bugs [23:29] that way lies insanity [23:30] subject prefix is always r"\[Bug (\d+)\]" [23:31] surely you can use regex [23:31] I thought I had a vague idea from copying the one that I found for dealing to mailing lists [23:35] ibeardslee: although I agree about using the reply-to header, more likely to be consistent [23:36] as someone can change the subject of the email simply by using email with a different subject and emailing the bug [23:37] but the reply-to header can be changed with someone emailing me privately [23:38] why do you want separate folders per bug? [23:38] I could understand a folder per package, perhaps [23:38] I'm in the process of rethinking that [23:39] although with OpenERP a bunch of bugs with the same project [23:39] hmmm [23:39] that's why mail clients have threading :) [23:50] * ibeardslee just moves all ^X-Launchpad-Bug: into the same folder while he ponders a bit more