Name of the process on the other end of a unix pipe?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
7
down vote

favorite
3












If two processes are connected by a pipe,



> cmd1 | cmd2


is there any way for cmd1 to find out the name (or PID) of the process on the other side of the pipe (cmd2)?



Also, vice versa, is there any way for cmd2 to get the name/PID of cmd1?



I know that there is isatty(3) to check if the output goes to (or the input comes from) a terminal, so I wondered if there is a way to find out a little bit more about the other hand side.







share|improve this question


















  • 1




    This would be platform-specific at best; where are you trying to do it?
    – Michael Homer
    Nov 18 '17 at 21:07










  • I'd be fine with a Linux-specific version.
    – shark.dp
    Nov 18 '17 at 21:09






  • 5




    In theory there could be more than one process on the other end of the pipe, if cmd2 forked.
    – Nate Eldredge
    Nov 19 '17 at 0:16







  • 6




    Although this may be possible, I really doubt that it's a good idea; this question smells like an XY problem.
    – Nate Eldredge
    Nov 19 '17 at 0:25










  • @NateEldredge Indeed: cmd1 | (cmd2 & cmd3)
    – Barmar
    Nov 22 '17 at 17:40














up vote
7
down vote

favorite
3












If two processes are connected by a pipe,



> cmd1 | cmd2


is there any way for cmd1 to find out the name (or PID) of the process on the other side of the pipe (cmd2)?



Also, vice versa, is there any way for cmd2 to get the name/PID of cmd1?



I know that there is isatty(3) to check if the output goes to (or the input comes from) a terminal, so I wondered if there is a way to find out a little bit more about the other hand side.







share|improve this question


















  • 1




    This would be platform-specific at best; where are you trying to do it?
    – Michael Homer
    Nov 18 '17 at 21:07










  • I'd be fine with a Linux-specific version.
    – shark.dp
    Nov 18 '17 at 21:09






  • 5




    In theory there could be more than one process on the other end of the pipe, if cmd2 forked.
    – Nate Eldredge
    Nov 19 '17 at 0:16







  • 6




    Although this may be possible, I really doubt that it's a good idea; this question smells like an XY problem.
    – Nate Eldredge
    Nov 19 '17 at 0:25










  • @NateEldredge Indeed: cmd1 | (cmd2 & cmd3)
    – Barmar
    Nov 22 '17 at 17:40












up vote
7
down vote

favorite
3









up vote
7
down vote

favorite
3






3





If two processes are connected by a pipe,



> cmd1 | cmd2


is there any way for cmd1 to find out the name (or PID) of the process on the other side of the pipe (cmd2)?



Also, vice versa, is there any way for cmd2 to get the name/PID of cmd1?



I know that there is isatty(3) to check if the output goes to (or the input comes from) a terminal, so I wondered if there is a way to find out a little bit more about the other hand side.







share|improve this question














If two processes are connected by a pipe,



> cmd1 | cmd2


is there any way for cmd1 to find out the name (or PID) of the process on the other side of the pipe (cmd2)?



Also, vice versa, is there any way for cmd2 to get the name/PID of cmd1?



I know that there is isatty(3) to check if the output goes to (or the input comes from) a terminal, so I wondered if there is a way to find out a little bit more about the other hand side.









share|improve this question













share|improve this question




share|improve this question








edited Nov 18 '17 at 21:09









Michael Homer

42.6k6108148




42.6k6108148










asked Nov 18 '17 at 21:00









shark.dp

1684




1684







  • 1




    This would be platform-specific at best; where are you trying to do it?
    – Michael Homer
    Nov 18 '17 at 21:07










  • I'd be fine with a Linux-specific version.
    – shark.dp
    Nov 18 '17 at 21:09






  • 5




    In theory there could be more than one process on the other end of the pipe, if cmd2 forked.
    – Nate Eldredge
    Nov 19 '17 at 0:16







  • 6




    Although this may be possible, I really doubt that it's a good idea; this question smells like an XY problem.
    – Nate Eldredge
    Nov 19 '17 at 0:25










  • @NateEldredge Indeed: cmd1 | (cmd2 & cmd3)
    – Barmar
    Nov 22 '17 at 17:40












  • 1




    This would be platform-specific at best; where are you trying to do it?
    – Michael Homer
    Nov 18 '17 at 21:07










  • I'd be fine with a Linux-specific version.
    – shark.dp
    Nov 18 '17 at 21:09






  • 5




    In theory there could be more than one process on the other end of the pipe, if cmd2 forked.
    – Nate Eldredge
    Nov 19 '17 at 0:16







  • 6




    Although this may be possible, I really doubt that it's a good idea; this question smells like an XY problem.
    – Nate Eldredge
    Nov 19 '17 at 0:25










  • @NateEldredge Indeed: cmd1 | (cmd2 & cmd3)
    – Barmar
    Nov 22 '17 at 17:40







1




1




This would be platform-specific at best; where are you trying to do it?
– Michael Homer
Nov 18 '17 at 21:07




This would be platform-specific at best; where are you trying to do it?
– Michael Homer
Nov 18 '17 at 21:07












I'd be fine with a Linux-specific version.
– shark.dp
Nov 18 '17 at 21:09




I'd be fine with a Linux-specific version.
– shark.dp
Nov 18 '17 at 21:09




5




5




In theory there could be more than one process on the other end of the pipe, if cmd2 forked.
– Nate Eldredge
Nov 19 '17 at 0:16





In theory there could be more than one process on the other end of the pipe, if cmd2 forked.
– Nate Eldredge
Nov 19 '17 at 0:16





6




6




Although this may be possible, I really doubt that it's a good idea; this question smells like an XY problem.
– Nate Eldredge
Nov 19 '17 at 0:25




Although this may be possible, I really doubt that it's a good idea; this question smells like an XY problem.
– Nate Eldredge
Nov 19 '17 at 0:25












@NateEldredge Indeed: cmd1 | (cmd2 & cmd3)
– Barmar
Nov 22 '17 at 17:40




@NateEldredge Indeed: cmd1 | (cmd2 & cmd3)
– Barmar
Nov 22 '17 at 17:40










1 Answer
1






active

oldest

votes

















up vote
13
down vote



accepted










You can see the pipe in /proc/$PID/fd. The descriptor is a symlink to something like pipe:[188528098]. With that information you can search for the other process:



$ lsof -n | grep -w 188528098
sleep 1565 hl 1w FIFO 0,12 0t0 188528098 pipe
sleep 1566 hl 0r FIFO 0,12 0t0 188528098 pipe


Or, if you want to be sure (for automatic processing) that the number is the socket and not part of a file name:



$ lsof -n | awk 'NF==9 && $5=="FIFO" && $9=="pipe" && $8==188528098'


With lsof 4.88 and above, you can also use the -E or +E flags:



In combination with -p <pid>, -d <descriptor>, you can get the endpoint information for a specific descriptor of a given pid.



$ sleep 1 | sh -c 'lsof -E -ap "$$" -d 0; exit'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sh 27176 chazelas 0r FIFO 0,10 0t0 2609460 pipe 27175,sleep,1w


Above telling us that fd 0 of sh is a pipe with fd 1 of sleep at the other end. If you change -E to +E, you also get the full information for that fd of sleep:



$ sleep 1 | sh -c 'lsof +E -ap "$$" -d 0; exit'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sleep 27066 chazelas 1w FIFO 0,10 0t0 2586272 pipe 27067,sh,0r 27068,lsof,0r
sh 27067 chazelas 0r FIFO 0,10 0t0 2586272 pipe 27066,sleep,1w


(see how lsof also has the pipe on its stdin)






share|improve this answer


















  • 6




    One should be prepared for this to fail; e.g. if the process on the other end has changed UIDs and you don't have permission to lsof it.
    – Nate Eldredge
    Nov 19 '17 at 0:24










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f405485%2fname-of-the-process-on-the-other-end-of-a-unix-pipe%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
13
down vote



accepted










You can see the pipe in /proc/$PID/fd. The descriptor is a symlink to something like pipe:[188528098]. With that information you can search for the other process:



$ lsof -n | grep -w 188528098
sleep 1565 hl 1w FIFO 0,12 0t0 188528098 pipe
sleep 1566 hl 0r FIFO 0,12 0t0 188528098 pipe


Or, if you want to be sure (for automatic processing) that the number is the socket and not part of a file name:



$ lsof -n | awk 'NF==9 && $5=="FIFO" && $9=="pipe" && $8==188528098'


With lsof 4.88 and above, you can also use the -E or +E flags:



In combination with -p <pid>, -d <descriptor>, you can get the endpoint information for a specific descriptor of a given pid.



$ sleep 1 | sh -c 'lsof -E -ap "$$" -d 0; exit'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sh 27176 chazelas 0r FIFO 0,10 0t0 2609460 pipe 27175,sleep,1w


Above telling us that fd 0 of sh is a pipe with fd 1 of sleep at the other end. If you change -E to +E, you also get the full information for that fd of sleep:



$ sleep 1 | sh -c 'lsof +E -ap "$$" -d 0; exit'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sleep 27066 chazelas 1w FIFO 0,10 0t0 2586272 pipe 27067,sh,0r 27068,lsof,0r
sh 27067 chazelas 0r FIFO 0,10 0t0 2586272 pipe 27066,sleep,1w


(see how lsof also has the pipe on its stdin)






share|improve this answer


















  • 6




    One should be prepared for this to fail; e.g. if the process on the other end has changed UIDs and you don't have permission to lsof it.
    – Nate Eldredge
    Nov 19 '17 at 0:24














up vote
13
down vote



accepted










You can see the pipe in /proc/$PID/fd. The descriptor is a symlink to something like pipe:[188528098]. With that information you can search for the other process:



$ lsof -n | grep -w 188528098
sleep 1565 hl 1w FIFO 0,12 0t0 188528098 pipe
sleep 1566 hl 0r FIFO 0,12 0t0 188528098 pipe


Or, if you want to be sure (for automatic processing) that the number is the socket and not part of a file name:



$ lsof -n | awk 'NF==9 && $5=="FIFO" && $9=="pipe" && $8==188528098'


With lsof 4.88 and above, you can also use the -E or +E flags:



In combination with -p <pid>, -d <descriptor>, you can get the endpoint information for a specific descriptor of a given pid.



$ sleep 1 | sh -c 'lsof -E -ap "$$" -d 0; exit'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sh 27176 chazelas 0r FIFO 0,10 0t0 2609460 pipe 27175,sleep,1w


Above telling us that fd 0 of sh is a pipe with fd 1 of sleep at the other end. If you change -E to +E, you also get the full information for that fd of sleep:



$ sleep 1 | sh -c 'lsof +E -ap "$$" -d 0; exit'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sleep 27066 chazelas 1w FIFO 0,10 0t0 2586272 pipe 27067,sh,0r 27068,lsof,0r
sh 27067 chazelas 0r FIFO 0,10 0t0 2586272 pipe 27066,sleep,1w


(see how lsof also has the pipe on its stdin)






share|improve this answer


















  • 6




    One should be prepared for this to fail; e.g. if the process on the other end has changed UIDs and you don't have permission to lsof it.
    – Nate Eldredge
    Nov 19 '17 at 0:24












up vote
13
down vote



accepted







up vote
13
down vote



accepted






You can see the pipe in /proc/$PID/fd. The descriptor is a symlink to something like pipe:[188528098]. With that information you can search for the other process:



$ lsof -n | grep -w 188528098
sleep 1565 hl 1w FIFO 0,12 0t0 188528098 pipe
sleep 1566 hl 0r FIFO 0,12 0t0 188528098 pipe


Or, if you want to be sure (for automatic processing) that the number is the socket and not part of a file name:



$ lsof -n | awk 'NF==9 && $5=="FIFO" && $9=="pipe" && $8==188528098'


With lsof 4.88 and above, you can also use the -E or +E flags:



In combination with -p <pid>, -d <descriptor>, you can get the endpoint information for a specific descriptor of a given pid.



$ sleep 1 | sh -c 'lsof -E -ap "$$" -d 0; exit'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sh 27176 chazelas 0r FIFO 0,10 0t0 2609460 pipe 27175,sleep,1w


Above telling us that fd 0 of sh is a pipe with fd 1 of sleep at the other end. If you change -E to +E, you also get the full information for that fd of sleep:



$ sleep 1 | sh -c 'lsof +E -ap "$$" -d 0; exit'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sleep 27066 chazelas 1w FIFO 0,10 0t0 2586272 pipe 27067,sh,0r 27068,lsof,0r
sh 27067 chazelas 0r FIFO 0,10 0t0 2586272 pipe 27066,sleep,1w


(see how lsof also has the pipe on its stdin)






share|improve this answer














You can see the pipe in /proc/$PID/fd. The descriptor is a symlink to something like pipe:[188528098]. With that information you can search for the other process:



$ lsof -n | grep -w 188528098
sleep 1565 hl 1w FIFO 0,12 0t0 188528098 pipe
sleep 1566 hl 0r FIFO 0,12 0t0 188528098 pipe


Or, if you want to be sure (for automatic processing) that the number is the socket and not part of a file name:



$ lsof -n | awk 'NF==9 && $5=="FIFO" && $9=="pipe" && $8==188528098'


With lsof 4.88 and above, you can also use the -E or +E flags:



In combination with -p <pid>, -d <descriptor>, you can get the endpoint information for a specific descriptor of a given pid.



$ sleep 1 | sh -c 'lsof -E -ap "$$" -d 0; exit'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sh 27176 chazelas 0r FIFO 0,10 0t0 2609460 pipe 27175,sleep,1w


Above telling us that fd 0 of sh is a pipe with fd 1 of sleep at the other end. If you change -E to +E, you also get the full information for that fd of sleep:



$ sleep 1 | sh -c 'lsof +E -ap "$$" -d 0; exit'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sleep 27066 chazelas 1w FIFO 0,10 0t0 2586272 pipe 27067,sh,0r 27068,lsof,0r
sh 27067 chazelas 0r FIFO 0,10 0t0 2586272 pipe 27066,sleep,1w


(see how lsof also has the pipe on its stdin)







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 18 '17 at 21:48

























answered Nov 18 '17 at 21:13









Hauke Laging

53.6k1282130




53.6k1282130







  • 6




    One should be prepared for this to fail; e.g. if the process on the other end has changed UIDs and you don't have permission to lsof it.
    – Nate Eldredge
    Nov 19 '17 at 0:24












  • 6




    One should be prepared for this to fail; e.g. if the process on the other end has changed UIDs and you don't have permission to lsof it.
    – Nate Eldredge
    Nov 19 '17 at 0:24







6




6




One should be prepared for this to fail; e.g. if the process on the other end has changed UIDs and you don't have permission to lsof it.
– Nate Eldredge
Nov 19 '17 at 0:24




One should be prepared for this to fail; e.g. if the process on the other end has changed UIDs and you don't have permission to lsof it.
– Nate Eldredge
Nov 19 '17 at 0:24

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f405485%2fname-of-the-process-on-the-other-end-of-a-unix-pipe%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?