Conversation with #inferno at Fri Dec  7 05:58:42 2012 on powerman@irc.freenode.net (irc)
(06:31:09) raphaelsc [~raphaelsc@187-127-98-222.user.veloxzone.com.br] entered the room.
(07:11:07) dreadlorde left the room (quit: Ping timeout: 256 seconds).
(07:17:54) raphaelsc left the room (quit: Ping timeout: 240 seconds).
(07:21:56) raphaelsc [~raphaelsc@187-127-98-222.user.veloxzone.com.br] entered the room.
(07:47:54) raphaelsc left the room (quit: Ping timeout: 240 seconds).
(09:50:19) Gegemon [~ynv@mx1.airis.ru] entered the room.
(10:17:04) redblue left the room (quit: Ping timeout: 252 seconds).
(10:17:46) `jpi left the room (quit: Ping timeout: 246 seconds).
(10:22:16) redblue [whois@24-230-226-60.tr.cgocable.ca] entered the room.
(10:23:16) `jpi [~jpi@unaffiliated/pseud0cod3r] entered the room.
(12:32:44) Aram [~aram@unaffiliated/aramdune] entered the room.
(14:13:45) dreadlorde [dreadlorde@c-68-42-82-10.hsd1.mi.comcast.net] entered the room.
(14:58:42) fdd [fdd@2a02:2f02:8029:f005::bc18:492e] entered the room.
(14:58:43) fdd left the room (quit: Changing host).
(14:58:43) fdd [fdd@unaffiliated/fdd] entered the room.
(15:10:55) Gegemon left the room (quit: Quit: Leaving.).
(17:14:56) powerman: did anyone ever tried to find out why exactly inferno sh is so slow?
(18:19:17) fdd left the room (quit: Read error: Connection reset by peer).
(18:19:48) fdd [fdd@unaffiliated/fdd] entered the room.
(18:25:55) Aram left the room (quit: Quit: .).
(18:39:44) raphaelsc [~raphaelsc@187-127-59-122.user.veloxzone.com.br] entered the room.
(20:17:34) anth_r: not as far as i'm aware. all the inferno shells have been very slow, though.
(21:40:34) rogpeppe left the room (quit: Ping timeout: 255 seconds).
(21:40:44) rogpeppe [~rog@host-92-30-186-158.as13285.net] entered the room.
(22:05:36) rogpeppe left the room (quit: *.net *.split).
(22:10:56) rogpeppe [~rog@host-92-30-186-158.as13285.net] entered the room.
(23:09:32) rogpeppe left the room (quit: Quit: Konversation terminated!).
(00:04:16) powerman: looks like env variable . (dot) is somewhat magic
(00:05:33) powerman: /env/. isn't a regular file, so this variable's value can't be stored there, and thus /dis/env doesn't list this variable
(00:07:01) powerman: but looks like sh cache env variables and use cached values when user request it with $varname
(00:08:08) powerman: so $. works. in shell where it was created. and in pseudo-subshell @{...}. but doesn't work in real subshell (started by /dis/sh)
(00:09:44) powerman: of course, same apply to variable .. (except we can't access it using $.. and need to do $'..')
(01:18:25) anth_r: powerman: interesting, i've never thought to try that. is that useful behavior for you? seems like "$." could get awkward in many cases for entirely non-technical reasons.
(01:21:09) powerman: anth_r: I'm not trying to find use case for it, I just wonder how 'fn .' (mentioned here several times before) works without creating variable . in /env… and while researching this I've found this magic.
(01:23:05) powerman: but invisible, non-exportable, available only in current shell variables may be useful in some security-related scripts, to keep passwords etc. :)
(01:24:41) leetspete: powerman: fn's and subfn's each get their own namespace.  'fn .' would go into '/env/fn-.'.
(01:24:56) powerman: fn . - yes. but not variable .
(01:24:59) leetspete: Right.
(01:25:29) powerman: fn . {args:=$*;if {! ~ $#args 0} {.=$*};$.}
(01:25:29) leetspete: It's a fun trick.
(01:32:52) powerman: btw, same apply to var names which contain /
(01:35:15) anth_r: for the record, rc behaves almost the same: setting the var, subshels and new rc instances all behave as you described.
(01:35:55) anth_r: but when references the variable directly, you get both the value and an error about a bad reference to /env/. or /env//.
(01:37:08) powerman: in rc? 'cos in sh there is no errors here
(01:37:22) anth_r: yup. i just figured i'd try it for comparison.
(01:47:15) powerman: what's the differences between executing commands in subshell using @{...} and sh -c {...}?
(01:47:43) powerman: I mean not related to $. trick, but intentional differences? Why @ was introduced?
(01:49:01) powerman: one I see is @{...} have same loaded modules, which sh -c {...} have no loaded modules
(01:49:52) powerman: another slight difference is @{...} doesn't fork namespace, so it's equal to sh -n -c {...}
(01:50:00) leetspete: powerman: pctl stuff.
(01:50:07) leetspete: Oh, you got it.
(01:50:35) leetspete: sh gets you '-n' or 'not -n'.
(01:50:46) powerman: leetspete: what pctl? @{pctl forkns;...} doesn't differ from sh -c {...}
(01:50:58) powerman: and @{...} is same as sh -n -c {...}
(01:51:42) powerman: fn @ {sh -n -c $1}
(01:52:01) powerman: is this worth adding special syntax to base sh?
(01:53:13) anth_r: it feels that way to me, but that may just be because i'm used to it.
(01:53:57) leetspete: powerman: I thought that all 'sh ...' did FORKFD.
(01:54:12) leetspete: But haven't checked if @ does it.
(01:55:29) leetspete: I'd assume @ also doesn't require reloading /dis/sh.dis (so you could do it in an empty namespace), but could be wrong.
(01:57:10) powerman: I've checked sources… :)
(01:57:27) powerman: Looks like main difference is copy or don't copy environment.
(01:58:03) powerman: @{…} will get original environment, not a copy of it like any other executed app including sh -c
(01:58:16) powerman: so it can modify it, EVEN after pctl forkns
(02:02:45) powerman: leetspete: as for spawning /dis/sh.dis, I think @{} will spawn it anyway, otherwise pctl trick won't work
(02:03:26) powerman: no, I'm wrong.
(02:04:40) powerman: @{} will spawn some function in already-loaded /dis/sh.dis, because it can't share adt with current environment with module loaded using Command interface
(02:05:35) powerman: or it can load /dis/sh.dis but using some other internal interface, not Command
(03:01:41) powerman: leetspete: looks like I manage to implement 'if' in bare sh (without load std) and almost implement 'for' :)
(03:04:25) powerman: done!
(03:05:22) powerman: ; do = { $* }
(03:05:22) powerman: ; dont = { }
(03:05:22) powerman: ; if = { (cmd cond) := $*; { $2 $cmd } $cond $do $dont }
(03:05:22) powerman: ; for = { (var in list) := $*; code := $$#*; $iter $var $code $list }
(03:05:22) powerman: ; iter = { (var code list) := $*; (cur list) := $list; (next unused) := $list; $if {$var=$cur; $code; $iter $var $code $list} $next }
(03:05:29) powerman: and now:
(03:05:40) powerman: ; $for i in 10 20 30 { echo i is $i }
(03:05:40) powerman: i is 10
(03:05:40) powerman: i is 20
(03:05:40) powerman: i is 30
(03:05:40) powerman: ; 
(03:05:53) powerman: :D
(03:24:36) leetspete: powerman: That is really clever.  :)
(03:26:00) powerman: yeah. now I understand why you like inferno sh. it's really amazing. only problem is it so slow :(
(03:27:12) leetspete: Your problem is you use Perl.  If you had been using Ruby for a few years, then sh would seem insanely fast. :)
(03:28:04) leetspete: Actually, I've been writing awk all day.
(03:28:59) powerman: sh always feels ugly to me. because it's slow. because it's use of non-paired " and ` (which break syntax highlight everywhere). because it's counter-intuitive absence of non-list variables. and because it's so hard to use interactively - no command history, no autocomplete, no feature-rich editing of command line.
(03:30:28) leetspete: You could do 'rlwrap -a' and get the whole readline thing.  I actually have gotten used to the way the graphical one works, though.
(03:30:58) leetspete: The non-paired "/` are a little weird, granted.
(03:31:29) powerman: but today I've forced myself to really learn it. I wanted really get it syntax to be able to implement syntax highlight rules for vim. but, surprise, looks like I'm beginning to understand and love it. :)
(03:33:47) leetspete: Cool!  :)
(03:34:35) leetspete: Egh, hard time concentrating.  Nicotine withdrawals.  Suppose I've got to run to the store, be back in 10-15.
(03:36:08) powerman: leetspete: thanks for rlwrap
(03:36:39) powerman: looks cool. probably it's even possible to manage to get filename completion relative to /usr/inferno
(04:13:52) anth_r: rlwrap
(04:14:05) anth_r: oy. stupid win.
(04:21:12) leetspete: I started using rlwrap nearly everywhere after I found out about it.
(04:23:03) leetspete: I'm mostly just using Inferno now, though.  A friend of mine has been on me about writing some Go.  It was nearly distressing having to do Linux after so much time living in Inferno.  :P
(04:31:21) powerman: leetspete: no, that's too much for me. :) I love inferno as runtime for my apps, but as workstation desktop… no, thanks. vim, mutt, pidgin, opera, rtorrent, mplayer… and fucking skype, which is buggy on linux, I hate it but have to use.
(04:33:38) powerman: hmm. I forget mc. probably just a bad habit from DOS time, when it was norton commander.
(04:33:47) leetspete: powerman: Yeah, for the time being, I still need finch and mplayer.
(04:34:11) powerman: and browser. charon is nice… example.
(04:34:23) leetspete: Yep, haha.
(04:36:32) leetspete: Skype for work stuff?  You're a freelancer, if I recall correctly.  Seems like that's the preferred method for consultants nowadays.
(04:39:40) powerman: yeah. some people in our team stick to skype, and it's easier to run it than to force them all to run any jabber/icq
(04:43:11) leetspete: Last two jobs I was at, everyone used Google Plus.  My /etc/hosts has '255.255.255.255 plus.google.com' in it.  So much arguing, haha.
(05:54:53) The account has disconnected and you are no longer in this chat. You will automatically rejoin the chat when the account reconnects.