[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
On Thu, Mar 04, 2004 at 11:02:58AM -0500, gabriel rosenkoetter wrote: > [29 lines, 198 words, 1094 characters] Top characters: teonaisr > > On Thu, Mar 04, 2004 at 10:40:13AM -0500, Martin DiViaio wrote: > > Anyone know of an easy way to find an open, non-priviledged TCP port in > > bash? > > > > I could troll through the output from netstat and then pick a port that > > isn't listed, but I'm hoping there is an easier solution. > > I don't think there is, since bash doesn't (or, at least, I sure > HOPE it doesn't) have any networking code internal to it. netstat or > lsof would be your best bets. It does if you compile with --enable-net-redirections. The bash man page doesn't mention that this is a compile-time option, but here's what it says in bash(1): Bash handles several filenames specially when they are used in redirec- tions, as described in the following table: /dev/fd/fd If fd is a valid integer, file descriptor fd is dupli- cated. /dev/stdin File descriptor 0 is duplicated. /dev/stdout File descriptor 1 is duplicated. /dev/stderr File descriptor 2 is duplicated. /dev/tcp/host/port If host is a valid hostname or Internet address, and port is an integer port number or service name, bash attempts to open a TCP connection to the corresponding socket. /dev/udp/host/port If host is a valid hostname or Internet address, and port is an integer port number or service name, bash attempts to open a UDP connection to the corresponding socket. A failure to open or create a file causes the redirection to fail. On the other hand, some degree of decorum is preserved for Debian users. In /usr/share/doc/bash/README.Debian.gz, we can read many interesting items, including this: 9. Why is bash configured with --disable-net-redirections? It can produce completely unexpected results. This kind of feature should not be part of a shell but a special. tool. And that tool has existed for years already, it's called netcat. > Why do you want to do this, though? Binding to "0" gets you an > unused socket which you then own, meaning there's no chance for a > race condition between when you get the number and start using the > socket. Hmm, that's cool, I didn't know that. Is that a bash-ism, a linux-ism, or can I really say this: sock = socket(AF_INET, SOCK_DGRAM, 0); memset(&saddr, 0, sizeof(saddr)); saddr.sin_family = AF_INET; saddr.sin_addr.s_addr = htonl(INADDR_ANY); saddr.sin_port = 0; /* Gabe said I could do this */ ret = bind(sock, (struct sockaddr *)&saddr, sizeof(saddr)); and expect it to work on most unices? > What problem are you trying to solve? He's trying to waste my time, because he knows I've been doing socket programming this week and am easily distracted by socket questions! ;-) -- Jeff Jeff Abrahamson <http://www.purple.com/jeff/> GPG fingerprint: 1A1A BA95 D082 A558 A276 63C6 16BF 8C4C 0D1D AE4B Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Attachment:
signature.asc
Description: Digital signature