Proc stdin weird behaviour

Can sombody explain why this happening and how to fix it so that the data sent to stdin behaves the same way as the data typed in to stdin.

If you look at the /proc/$pid/fd, it is a sym link to a pts device:

$ ls -l /proc/1703/fd/
total 0
dr-x------ 2 chris users  0 Aug 14 17:03 ./
dr-xr-xr-x 9 chris users  0 Aug 14 17:03 ../
lrwx------ 1 chris users 64 Aug 14 17:03 0 -> /dev/pts/2
lrwx------ 1 chris users 64 Aug 14 17:04 1 -> /dev/pts/2
lrwx------ 1 chris users 64 Aug 14 17:03 2 -> /dev/pts/2
lrwx------ 1 chris users 64 Aug 14 17:04 4 -> socket:[44154435]

What you are doing is the same as writing to the pts:

$ echo hello > /dev/pts/2

There must be a way to make chars available for reading on the pts, as that is what the terminal window is doing when you type into it. It may involve hacking the terminal code, I’m not sure.

Yeah i just fucking gave up because it was not worth it. Instead i just wrote a python script.

import socket
from os import system
from sys import platform as _platform

def clear():
  if _platform == "linux" or _platform == "linux2" or _platform == "darwin":
    system("clear")
  elif _platform == "win32" or _platform == "win64":
    system("cls")
  return

ip   = "127.0.0.1"
port = 4005
lenBuffer = 1024

commands = {"new"    : "\x30\x02\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x05\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x6c\x6f\x6c",
            "select" : "\x20\x6c\x6f\x6c", 
            "flush"  : "\x40"}


s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
  s.connect((ip, port))
except ConnectionRefusedError:
  print("[ERROR] Server is not online.")
else:
  print("SaturnDB Interactive Testing Tool")

  while True:
    command = input(">> ")
    if(command in commands):
      s.send(bytes(commands[command], "utf-8"))
    elif command == "q" or command == "exit":
      break
    elif command == "clear":
      clear()
    else:
      print("[ERROR] Command does not exist.")

  s.close()
2 Likes

This might be job for tmux:

$ tmux new -s myterm

In another terminal:

$ tmux send-keys -t myterm "ls" ENTER

The ā€˜ls’ command is sent to the tmux session ā€œmytermā€ and executed in the bash shell.

Yeah so actually made a Unix stack exchange things aswell: https://unix.stackexchange.com/questions/462630/proc-stdin-weird-behaviour

But your solution is better though can you send hexadecimal data? Because that was the whole purpose of this thing.

By hexadecimal I mean binary but escaped with hex like 0x0A

All I know about it is through the man page. I’d have to dig deeper than that to determine what kind stuff you can do.

This looks like the a similar feature request: https://github.com/tmux/tmux/issues/1186

Can you explain what the problem is here? It looks like it’s doing what it should be to me…
Oh I should have read the stackexchange post, you were expecting the echoed text to show up in the netcat server terminal. Yep the characters you type are echoed by the terminal, not netcat.

Yup…

I actually just made my own tool. Not done yet but.

https://nwshell.com

nwshell isn’t reachable yet…

$ traceroute nwshell.com
...
 5  te0-6-0-4.rcr21.b003070-1.sfo01.atlas.cogentco.com (38.88.216.117)  3.482 ms  3.484 ms  3.478 ms
 6  be2682.ccr22.sfo01.atlas.cogentco.com (154.54.6.169)  3.468 ms be2681.ccr21.sfo01.atlas.cogentco.com (154.54.5.233)  3.121 ms be2682.ccr22.sfo01.atlas.cogentco.com (154.54.6.169)  3.115 ms
 7  be2016.ccr31.sjc04.atlas.cogentco.com (154.54.0.178)  3.126 ms  3.044 ms  2.909 ms
 8  palo-b1-link.telia.net (62.115.34.73)  2.865 ms  2.860 ms  2.834 ms
 9  nyk-bb3-link.telia.net (62.115.114.4)  99.324 ms nyk-bb4-link.telia.net (62.115.122.37)  89.123 ms nyk-bb3-link.telia.net (62.115.114.4)  94.681 ms
10  nyk-b5-link.telia.net (80.91.254.14)  72.154 ms ash-bb3-link.telia.net (62.115.141.244)  90.093 ms  90.104 ms
11  cha-b1-link.telia.net (80.91.252.101)  84.403 ms  84.397 ms  84.372 ms
12  giglinx-ic-156088-cha-b1.c.telia.net (213.248.68.138)  101.506 ms  101.503 ms  100.835 ms
13  * * *
14  * * *
15  ashv1.main-hosting.com (208.69.231.10)  83.618 ms  83.480 ms  83.583 ms
16  * * giglinx-ic-156088-cha-b1.c.telia.net (213.248.68.138)  103.501 ms
17  * * *
18  * * *
19  * ashv1.main-hosting.com (208.69.231.10)  80.672 ms *
20  * * *

That’s fucking weird it works for me on chrome. Maybe some of the DNS servers need to update.

It resolves to 31.170.160.61 on my side.

Country?

I’m in California.

that’s maybe it

they maybe updated the european servers first instead

I’ll try later…

Link works now!

A use for this would be an interactive binary protocol?