Conversation

Notices

1. Embed this notice
   laurel (laurel@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 01:23:40 JST laurel

   • pistolero :thispersondoesnotexist:
   @p
   
   I'm trying to connect to plan9 using hubfs following the "Connecting from Other operating systems" part from here (https://9p.io/wiki/plan9/hubfs/index.html) and need some tech support.
   
   I have plan9 running in a virtualBox VM. I have forwarded port 8787 (tcp and udp) to localhost.
   Image 1 is what I run in the plan9 terminal.
   >Host:
   mkdir hubfs
   9pfuse 'tcp!127.0.0.1!8787' hubfs
   Output Error:
   9pfuse: fsmount: fsversion: fsrpc: muxrpc: unexpected eof
   
   Fuse kernel module is loaded.
   It is being used by a process but have no idea which one.
   fuse 122880 1
   I tested fuse using sshfs and fusermount and it works normally.
   
   I went into plan9port/src/cmd/9pfuse and rebuilt it (mk install) just in case.
   
   Here's a telnet output for the same port in case it helps:
   telnet 127.0.0.1 8787
   Trying 127.0.0.1...
   Connected to 127.0.0.1.
   Escape character is '^]'.
   Connection closed by foreign host.
   p9term.png
   • pistolero :thispersondoesnotexist: likes this.
   • Embed this notice
     laurel (laurel@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 01:23:41 JST laurel

     in reply to

     • pistolero :thispersondoesnotexist:
     @p
     
     Ok problem solved
     pistolero :thispersondoesnotexist: likes this.
   • Embed this notice
     pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 01:23:52 JST pistolero :thispersondoesnotexist:

     in reply to
     @laurel Oh, what was the problem?
   • Embed this notice
     laurel (laurel@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 01:56:09 JST laurel

     in reply to

     • pistolero :thispersondoesnotexist:
     @p
     
     I have no idea. Only thing I can think of is virtualBox not applying the port forward.
     Everything else was identical.
     
     I'm using:
     cat hubfs/io1 &
     cat hubfs/io2 &
     cat >>hubfs/io0
     
     with rlwrap to get something like a terminal.
     Is there a way to send sigint? Is there some other way to get a terminal that can be wrapped in rlwrap and support sigint?
     pistolero :thispersondoesnotexist: likes this.
   • Embed this notice
     pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 02:00:36 JST pistolero :thispersondoesnotexist:

     in reply to
     @laurel
     
     > Is there a way to send sigint?
     
     Not through rlwrap, I think. You could maybe %freeze, spawn a new shell, and then %thaw.
   • Embed this notice
     pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 02:01:00 JST pistolero :thispersondoesnotexist:

     in reply to

     • pistolero :thispersondoesnotexist:
     @laurel
     
     s/spawn a new shell,/spawn a new shell to kill the process you want killed/
   • Embed this notice
     laurel (laurel@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 03:46:29 JST laurel

     in reply to

     • pistolero :thispersondoesnotexist:
     @p
     
     I used the rc $apid variable to get the apid of the last process but how do I kill a process by pid?
     kill command only seems to accept a name input. I'm pretty sure that a :go: script would do the trick but there's gotta be a simpler way.
     Also, what's %thaw and %freeze, tried to search for them but got nothing.
     pistolero :thispersondoesnotexist: likes this.
   • Embed this notice
     pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 03:48:28 JST pistolero :thispersondoesnotexist:

     in reply to
     @laurel
     
     > how do I kill a process by pid?
     
     `kill pid` works.
     
     > Also, what's %thaw and %freeze,
     
     hubfs things. %freeze blocks the three file descriptors, %thaw undoes a %freeze.
   • Embed this notice
     laurel (laurel@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 04:07:01 JST laurel

     in reply to

     • pistolero :thispersondoesnotexist:
     @p
     
     ok,
     echo stop >> /proc/[pid]/ctl
     echo kill >> /proc/[pid]/ctl
     did it just fine
     pistolero :thispersondoesnotexist: likes this.
   • Embed this notice
     laurel (laurel@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 04:24:50 JST laurel

     in reply to

     • pistolero :thispersondoesnotexist:
     @p
     
     >`kill pid` works.
     It doesn't seem to work for me.
     killPid1.png
     pistolero :thispersondoesnotexist: likes this.
   • Embed this notice
     pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 04:25:42 JST pistolero :thispersondoesnotexist:

     in reply to
     @laurel Shit, you are right, I just looked at the source. I usually kill by `kill $name|rc`.
   • Embed this notice
     eisai (eisai@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 05:58:37 JST eisai

     in reply to

     • pistolero :thispersondoesnotexist:
     @p @laurel This is me reading this thread:
      ­
     82813468_p0.png
     pistolero :thispersondoesnotexist: likes this.
   • Embed this notice
     pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 05:58:53 JST pistolero :thispersondoesnotexist:

     in reply to

     • eisai
     @eisai @laurel Which one are you?
   • Embed this notice
     eisai (eisai@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 06:13:38 JST eisai

     in reply to

     • pistolero :thispersondoesnotexist:
     @p @laurel The grass outside.
     pistolero :thispersondoesnotexist: likes this.
   • Embed this notice
     pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 06:13:46 JST pistolero :thispersondoesnotexist:

     in reply to

     • eisai
     @eisai @laurel :brandt:
     ✙ dcc :pedomustdie: :phear_slackware: likes this.
   • Embed this notice
     laurel (laurel@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 17:57:46 JST laurel

     in reply to

     • pistolero :thispersondoesnotexist:
     @p
     
     Alright, after playing with hubfs a little more I think I finally get it and I have a very comfortable environment in plan9.
     I find it a lot easier to work with terminals than with drawterm. Should have tried connecting like this from the beginning.
     Telling you to use 9pfuse also teaches you how to mount folders/files that you can then edit with your preferred method, basically creating a development environment. I use something similar with sshfs and ssh when developing things on VMs.
     
     Btw, how do you stop the share/hubfs?
     pistolero :thispersondoesnotexist: likes this.
   • Embed this notice
     pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 19:00:31 JST pistolero :thispersondoesnotexist:

     in reply to
     @laurel
     
     > I find it a lot easier to work with terminals than with drawterm. Should have tried connecting like this from the beginning.
     
     I don't know, until I had to get used to it, I couldn't quite get used to "no more vt100". Once I did try to live in it a while, though, I didn't want to go back after. (I mean, ultimately that's a matter of UI preference, so whatever works, but I think the GUI tools are really nice, gping and histogram and the FS interfaces for rio/acme/etc., worth trying out.)
     
     > I use something similar with sshfs and ssh when developing things on VMs.
     
     Ha, yeah, I'm going in the opposite direction: I use sshfs on Plan 9 or /mnt/term so that I can interact with external systems and use Plan 9 as the dev environment.
     
     > Btw, how do you stop the share/hubfs?
     
     You can just rm /srv/hubfs (or whatever name you've given it). (Usage of /srv is very interesting: you write a file descriptor to /srv/$name and other processes' reads/writes to /srv/$name come through that file descriptor. rm'ing that file closes the file descriptor. The example code at the bottom of srv(3) is probably the best explanation of the facility.)
   • Embed this notice
     pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 21:09:43 JST pistolero :thispersondoesnotexist:

     in reply to
     @laurel
     
     > made me *read* the code.
     
     This is beautiful, I think.
     
     > I just prefer emacs.
     
     When I were a lad I would get worked up about this kind of thing, but I think I showed you the Arthur Whitney thing, didn't I? I mean, Unix was created with ed, and then I see this paragraph about Arthur Whitney working on K, "it was running Windows XP and had five windows open: two MS-DOS and three Notepad. Brutally simple IDE."
     http://archive.vector.org.uk/art10501320 .
     
     > the [cat] commands on the linux side
     
     Oh, oh, right, yeah. You were just doing `cat &`. Yeah, so you do wanna exit the stuff inside the hub and you will want to do something slightly nicer than just cats.
     
     If it gets stuck, `sudo umount -l` will get rid of FUSE filesystems as well.
     
     > Oh, so they are basically pipes that you can share over a network. Nice.
     
     Yeah, if you've ever used Unix sockets, those are somewhat simple but even they look like a pain compared to /srv.
   • Embed this notice
     laurel (laurel@freespeechextremist.com)'s status on Saturday, 07-Oct-2023 21:09:44 JST laurel

     in reply to

     • pistolero :thispersondoesnotexist:
     @p
     
     >but I think the GUI tools are really nice, gping and histogram and the FS interfaces for rio/acme/etc
     They are very nice and I did use acme quite a lot on my Linux host. I even modded the source a bit, and it changed the way I use text editors in general, made me *read* the code. But after modding emacs in that direction (removing code highlighting, using a light theme, adding extensive mouse support with tabs and right click, removing a lot of other things) I just prefer emacs.
     
     >You can just rm /srv/hubfs
     I did that first thing, along with /n/hubfs/*, but after reading your comment I looked a bit more into it. What ended up happening was that the [cat] commands on the linux side would go into uninterruptible sleep and prevent me from unmounting. I needed to first send something on the file they were waiting for, let them close, and then 'fusermount -u'.
     
     >the bottom of srv(3) is probably the best explanation of the facility.
     Oh, so they are basically pipes that you can share over a network. Nice.
     pistolero :thispersondoesnotexist: likes this.