On 11:31, Ville Skyttä wrote:
On Thursday 05 November 2009, Ville Skyttä wrote:
I'd like to propose two coding style guidelines:
No comments? Silence means acceptance?
+1 Another +1 to add the rationale to the documentation as well.
___
On 11:06, Ville Skyttä wrote:
Just for kicks, did you try other TERM values, for example vt110?
Using these commands
- interactive: ./runUnit _known_hosts_real.exp --debug
- cron/batch: ./runUnit _known_hosts_real.exp --debug /dev/tty40
These are the results for other terminal settings:
Hi,
all those precited commands use the .netrc file if it exists.
I would like to have some support for it.
Kind of :
[[ -r $HOME/.netrc ]] \
netrc_hosts=( $(compgen -W $(sed -n 's/.*[[:blank:] ]*machine \([^
[:blank:]]*\).*/\1/p' $HOME/.netrc) -- ${cur:-1}) ) \
COMPREPLY=(
On 091120 15:13, gibbo...@gmail.com wrote:
Should this go into _known_hosts_real ? _known_host_netrc ? ${1} or
SIDE NOTE: If all agree `_known_hosts_real' gets renamed to
`__known_hosts'?
That said, I'd rather have a separate `__hosts_netrc' and keep
`_known_hosts_real' for completing commands
I didn't dig it enough but it seems
that redirecting the output of some built-ins
(and even commands) seems sometimes broken, eg :
typeset -p /tmTAB [nothing] when it should
append p/.
(also look at http://bugs.gentoo.org/show_bug.cgi?id=285428)
It happens with 1.0, corrected in the gentoo 1.1
Hi,
I sometimes have to use the mount options
manually (eg, -o ro,users, ...)
I would like to know if there are any plans to
move it outside _the venerable_ bash_completion script.
To do this option completion (if it's interesting enough) it needs :
I) get the fstype, so grab the -t option in
Hello,
I'm not sure if I've asked this before, but why do we have the generated HTML
doc in git, and why is it in a such an oddly named dir (html~)? Was the
idea that the trailing ~ in the dirname would make git treat it as a backup
file and auto-ignore it? It's not happening for me. The
On Friday 20 November 2009, Freddy Vulto wrote:
Can you email these lines from your `dbg.log' showing the failing matches
just above the test yielding a FAIL? Maybe there's a sort order mismatch
between tcl/expect bash? We should be able to tell from these lines.
Close, but not quite: