Weblogs for drgraefy
So I'm trying to figure out how to prepopulate the prompt for the bash read function with text that could be edited and then passed to the readline output. For some reason I'm having an exceptionally hard time figuring out how to do this. It's either not possible, or I'm just having no luck. For example
The read help says that "One line is read from the standard input", but that doesn't actually seem to be the case:
servo:/tmp/cdtemp.VI3235 0$ foo= servo:/tmp/cdtemp.VI3235 0$ read -e -p : foo :asdf servo:/tmp/cdtemp.VI3235 0$ echo $foo asdf servo:/tmp/cdtemp.VI3235 0$ foo= servo:/tmp/cdtemp.VI3235 0$ echo -n asdf | read -e -p : foo servo:/tmp/cdtemp.VI3235 1$ echo $foo servo:/tmp/cdtemp.VI3235 0$ echo asdf >bar servo:/tmp/cdtemp.VI3235 0$ read -e -p : foo < bar servo:/tmp/cdtemp.VI3235 0$ echo $foo asdf servo:/tmp/cdtemp.VI3235 0$
This appears to indicate that read can accept input from a file, but not from a pipe. Why would that be?
Does anyone know how to prepopulate a read or readline prompt? Maybe it's not possible with read, but with some other function? It must be possible if I were to code it in C or something, cause plenty programs that do stuff like this (take the emacs mini-buffer, for instance).
For the better part of the last year, I have been struggling with a frustrating svn problem. My group's svn is served through apache2+ssl. Seemingly totally inconsitently, svn checkouts/updates would hang indefinitely, a "C-c" the only way to escape. Certain files would seem to be especially problematic, but again not consistently. Most times, but not always, hangs would be accompanied by the following message in /var/log/apache/error.log:
[Thu Feb 22 12:46:37 2007] [error] [client 1.2.3.4] Provider encountered an error while streaming a REPORT response. [500, #0] [Thu Feb 22 12:46:37 2007] [error] [client 1.2.3.4] A failure occurred while driving the update report editor [500, #104] [Thu Feb 22 12:46:37 2007] [error] [client 1.2.3.4] Error writing base64 data: Connection reset by peer [500, #104]
I have been trying for months to figure out what the problem is, but to no avail. Numerous google searches turned up people with similar issues, but never with any indication of what the problem might actually be, or how to get around it. Finally, after much struggle, we had a breakthrough yesterday.
Our network is on a private NAT'd lan. We finally noticed that the hangs were only occuring on machines located on our internal lan, and not for machines on the wan. This was a curious and important revelation. Internally the fqdn of our web site (foo.bar for the sake of argument), which resides on a server in our private lan, maps to our external IP address (1.2.3.4), just as it does externally, which in turn corresponds to the wan port of our crappy D-Link router/gateway. External ports 80 and 443 at 1.2.3.4 are then mapped to the web server (10.0.0.5).
What does this mean? Well, it means that internally, requests for foo.bar are first routed to the wan port of the router, which then sends them back to the web server. Apparently this was causing our crappy little router to choke, and drop connections. To confirm this, we changed the internal DNS to point foo.bar to the web server 10.0.0.5 directly. Once this was done, no more svn checkout/update hangs.
It's funny this never seemed to manifest itself elsewhere, but we don't do much heavy data transfer internally from the web server over ssl, except via svn. Basically the router couldn't turn around ssl packets fast enough. Ultimately, the problem is that we are running our network on a private, NAT'd lan. We shouldn't have to do this, and it's always a pain in the ass for one reason or another. As a wise man once quoted to me: 'NAT is not the answer. "NAT?" is the question, and the answer is "NOT!"'.
ape@local:0:~$ svn co --username chimp svn+ssh://remote/path/to/repoAfter a little bit of research, I found a relevant debian bug report filed against subversion. In it the reporter mentions something that works for him, that I confirmed does the trick: the username goes in the url:
ape@local:0:~$ svn co svn+ssh://chimp@remote/path/to/repoClearly this is still a bug with the svn client for not passing the username argument properly, but at least there's an easy way to get around it.
I have a server running munin-node. Almost 200 times a day (probably about 2/3 of the instances of munin-node running) I get a message such as the following in the kern.log:
Oct 18 23:00:06 chez kernel: munin-update[22368] general protection rip:2aacef9b51bd rsp:7fffbbe6f5b0 error:0
I have been able to find essentially no information to explain why this is happening, or even what the error means. Is anyone familiar with anything like this? Any help would be hugely appreciated.
]
Sometimes I make a separate partition for scratch, but I'm still undecided it's worth the trouble or not. I also usually put /tmp on a tempfs, which I think makes a lot more sense.
]