similar to: Why dup()?

Hello all, My scripts, which read stdout from ssh, weren't seeing EOF from the remote session.? It was being sent, but lost.? I tracked it down to the following code, in ssh.c, at ssh_session2_open: ??????? if (stdin_null_flag) { ??????????????? in = open(_PATH_DEVNULL, O_RDONLY); ??????? } else { ??????????????? in = dup(STDIN_FILENO); ??????? } ??????? out = dup(STDOUT_FILENO);

On Fri, 20 Oct 2017, David Newall wrote: > WHAT CAN I DO TO HELP STEWARD THIS CHANGE INTO THE MASTER SOURCE? > What do I need to do? Stop yelling and go file a bug at https://bugzilla.mindrot.org/ As I mentioned previously, your suggested change is wrong and we'd (at least) need to replace fd 1 with /dev/null prior to assigning it to the channel. -d

On 13/10/17 16:22, Damien Miller wrote: > At a minimum, I think we'd have to dup2 a fd to /dev/null to > STDOUT_FILENO so writes to stdout (e.g. from ill-behaved > libraries) have somewhere to go. Would that really be useful?? Output from Ill-behaved libraries, written fd 1, already go to the same place.? Don't forget, dup does not create a new file, it creates a duplicate

On 12/10/17 12:54, Clark Wang wrote: > How did you hit the problem? "ssh host echo hello | cat" works fine > for me. That's because ssh exited, not because of EOF. Consider the following: ?? ssh localhost 'exec cat > /dev/null' | { read l; echo ${l:-EOF}; } One should see "EOF" immediately (for values of immediate that include startup latency), but

On 14/10/17 07:44, Damien Miller wrote: > On Fri, 13 Oct 2017, David Newall wrote: >> On 13/10/17 16:22, Damien Miller wrote: >> > At a minimum, I think we'd have to dup2 a fd to /dev/null to >> > STDOUT_FILENO so writes to stdout (e.g. from ill-behaved >> > libraries) have somewhere to go. >> >> Would that really be useful?? Output from

Please review the function below, forkoff(), meant to be used in clientloop.c instead of daemon() and the code in process_escapes(). The intention is to make ~D ( like ~& but also detach) possible and to make it possible for ssh -f (or ssh -f -f - see other thread on this) to detach, not just forkoff(). I also intend to use the same detach technique in a feature patch for the hang-on-exit

Tried the user discussion list to no avail, can't get 3.6.p2 portable running due to buffer_get errors. Does the latest portable SNAP incorporate the latest patches? Running Red Hat 8.0 AS SHIPPED /usr/sbin/sshd ... cool, listens on 22 with 3.4p1 WITH 3.6.1p2 ./configure make make install ... /usr/local/sbin/sshd -t -f /usr/local/etc/sshd_config buffer_get: trying to get more bytes 1 than

Hi, I would like to follow up on the recent discussion on the mailing list about requirements for new backends[1] by submitting the following proposal for a staging area for new LLVM backends. This proposal incorporates ideas from Owen, Chandler, and others who chimed in on the original thread, and I hope the LLVM developers will be able to come to a consensus on this proposal or a modified

On 03/15/2019 12:49 AM, Jeremy Lin wrote: > [...] connecting to hosts where the host key > changes frequently. I realize this is a fairly niche use case [...] Doesn't StrictHostKeyChecking=no do what is wanted?

Hello all, I''m not sure who Camping''s steward is at this point(zimbatm? _why?), but I haven''t seen much activity in quite some time. I really like Camping, and I understand open source projects can fall by the wayside. So, I''d be willing to take over maintenance and releasing. I have experience maintaining my own open source projects, and a history of

Hi, Now that --enable-experimental-targets build flags have been added to the build systems. What needs to be done in order to get the R600 backend added as an experimental target? I've posted an updated version of the backend to llvm-commits[1], that addresses many of the criticisms of the backend, but I haven't received any feedback, and I feel like the submission process has stalled.

On 13/04/18 07:59, Josh Soref wrote: > Randall S. Becker <rsbecker at nexbridge.com> wrote: > >> -REGRESSTMP = "$(PWD)/regress" >> +REGRESSTMP = `pwd` >> >> ? tests interop-tests t-exec unit: regress-prep regress-binaries >> $(TARGETS) >> > It looks like the problem is that pwd is in uppercase, not so much the > distinction between

Hi, I would like to try to keep the staging area discussion going. There seems to be a general consensus that a staging area for backends and also new features would be acceptable for the LLVM project. What actions are required to make the staging area a reality? Is more discussion needed? Is anyone willing to volunteer to be the "Code Owner" for the staging area, to help move the

Dear Tom, Looks like setting LCOMMDirectiveType in AMDGPUMCAsmInfo.cpp is not needed anymore? I commented it out, and then LLVM got compiled fine. - D. 2012/9/6 Tom Stellard <tstellar at gmail.com>: > Hi, > > Now that --enable-experimental-targets build flags have been added to > the build systems. What needs to be done in order to get the R600 > backend added as an

On 6 February 2018 at 20:09, David Newall <openssh at davidnewall.com> wrote: > Do we need to do anything? It's not clear to me how SSH is vulnerable to > Spectre -- that is, how SSH can be used to execute a Spectre attack? I am more concerned with it being the target of a Spectre style attack. There's some long lived private data (host keys in the case of sshd, session keys

On 31/12/17 13:52, Peter Moody wrote: >> By making it impossible for people to use SSH > nb, it's not impossible to use opessh. it might not be possible to use > a*modern* openssh client to connect to an old, unpatched unmaintained > (by the vendor) sshd. i'd argue that's not the client's fault. Of course it's the client's fault.? The client worked, was

On 07/27/2012 01:01 PM, Tom Stellard wrote: > Hi, > > I would like to try to keep the staging area discussion going. There > seems to be a general consensus that a staging area for backends and also > new features would be acceptable for the LLVM project. What actions > are required to make the staging area a reality? Is more discussion > needed? Is anyone willing to

On Mon, 4 Nov 2019 at 14:07, David Newall <openssh at davidnewall.com> wrote: > [about scp] That's just awful, and I should have > thought it was not at all necessary. Am I missing something? > If you're saying that the scp protocol is an unfixable mess then the openssh team has been agreeing[0] with you for at least a decade and a half. We fix what we can, but some

-- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -------------- next part -------------- >From 8f1b06f64807239d4b4c923af4db8626a866ff6f Mon Sep 17

> Case in point; EAGAIN can come if you give your fd to another process > and continue using it yourself. > Short counts; It is documented behavior that read() and write() may > return short counts. It is not documented why, so you can not make > any assumptions. You might be right about short counts but if you're right about EAGAIN, there are bugs everywhere. My first