Terminal Oddness
Gavin
If I open a fresh Terminal Windows, I get it in Ocean which I like.
However, if I close the Window down BUT NOT the app, the next time I
invoke a window its the standard basic white on black! Why?
And also, when at the bash prompt, if I up arrow, then I get all
previous commands repeated (much like doskey), why doesnt it do it when
in nslookup?
--
Gavin. ACSP 10.5
http://www.stoof.co.uk
http://www.twitter.com/gavin_wilby
Ian McCall
> ...also, when at the bash prompt, if I up arrow, then I get all
> previous commands repeated (much like doskey), why doesnt it do it when
> in nslookup?
Sounds like it wasn't compiled with readline support.
Cheers,
Ian
David Empson
> Small thing here but annoying none the less, and it did it in 10.6 as well.
>
> If I open a fresh Terminal Windows, I get it in Ocean which I like.
>
> However, if I close the Window down BUT NOT the app, the next time I
> invoke a window its the standard basic white on black! Why?
For some reason, Terminal has a separate setting for its first window
and subsequently opened ones. In Terminal > Preferences:
Startup > On startup, open New window with settings > pick one for the
first window opened on launch.
Settings > Select a window style from the list on the left (or customize
the settings), then click the Default button to make the selected one
the default for the second and subsequent windows.
You can also change the active window's settings then use File > Use
Settings as Default.
> And also, when at the bash prompt, if I up arrow, then I get all
> previous commands repeated (much like doskey), why doesnt it do it when
> in nslookup?
Because the command line history recall via up-arrow is a feature of
bash (and other shells), and it is not replicated by nslookup.
--
David Empson
dem...@actrix.gen.nz
Ben Shimmin
> Small thing here but annoying none the less, and it did it in 10.6 as
> well.
>
> If I open a fresh Terminal Windows, I get it in Ocean which I like.
>
> However, if I close the Window down BUT NOT the app, the next time I
> invoke a window its the standard basic white on black! Why?
Have you tried clicking `Use settings as default' under Shell once you
have it looked the way you want?
Perhaps also make sure in `Startup' under Preferences you have
it set to open your settings on startup.
> And also, when at the bash prompt, if I up arrow, then I get all
> previous commands repeated (much like doskey), why doesnt it do it when
> in nslookup?
Surely everyone uses dig(1) these days, no?
b.
--
<b...@bas.me.uk> <URL:http://bas.me.uk/>
`Property, marriage, the law; as the bed to the river, so rule
and convention to the instinct; and woe to him who tampers with
the banks while the flood is flowing.' -- Samuel Butler, _Erewhon_
Gavin
> Startup > On startup, open New window with settings > pick one for the
> first window opened on launch.
>
> Settings > Select a window style from the list on the left (or customize
> the settings), then click the Default button to make the selected one
> the default for the second and subsequent windows.
Thats got it, how very odd, the prefs dont really make sense, but thank you.
Rowland McDonnell
> Gavin <gwilby...@stoof.co.uk>:
[snip]
> > And also, when at the bash prompt, if I up arrow, then I get all
> > previous commands repeated (much like doskey), why doesnt it do it when
> > in nslookup?
>
> Surely everyone uses dig(1) these days, no?
What an absurd suggestion - of course not!
That is obvious because most people have never heard of dig(1).
Me, for example.
Rowland.
--
Remove the animal for email address: rowland....@dog.physics.org
Sorry - the spam got to me
http://www.mag-uk.org http://www.bmf.co.uk
UK biker? Join MAG and the BMF and stop the Eurocrats banning biking
James Taylor
> Surely everyone uses dig(1) these days, no?
Why would anyone prefer to use dig's verbose command lines and verbose
output when host is so much neater?
$ host <domain name>
Gives the IP, and any canonical names
$ host <ip>
Gives the reverse DNS names
$ host -t <type> <domain name>
Gives the resource records of type <type>
Of course, the only reason to use nslookup is if you're using BusyBox or
Windows (similarly limited functionality).
Is there anything you can do with dig that host doesn't do?
--
James Taylor
Ben Shimmin
Read the manpages. Certainly host(1) can do most common things, but
dig(1) has some cool extras -- eg. it can do multiple queries in
one swoop.
You can also use `+short' if dig(1)'s verbose output bothers you.
James Taylor
> Read the manpages. Certainly host(1) can do most common things, but
> dig(1) has some cool extras -- eg. it can do multiple queries in
> one swoop.
Listing multiple names on a single command line is not necessarily much
better than querying for each one as needed while you research, and if
you did have a great many names (or IPs) to query you might be better
reading them from a file like so:
xargs -L 1 host < names.txt
> You can also use `+short' if dig(1)'s verbose output bothers you.
That's a prime example of dig's verbosity! If you have to use such a
clumsy verbose option to avoid getting a verbose screenful of output
with a very low signal to noise ratio, then really there's no gain in
convenience. Many of dig's options are similarly verbose, which is fine
for scripting, but not for a casual command line query tool. A good Unix
command's output should be concise by default, and a -v option should
make it more verbose. Which is exactly how host behaves, of course.
--
James Taylor
Ben Shimmin
> Ben Shimmin wrote:
>> Read the manpages. Certainly host(1) can do most common things, but
>> dig(1) has some cool extras -- eg. it can do multiple queries in
>> one swoop.
>
> Listing multiple names on a single command line is not necessarily much
> better than querying for each one as needed while you research, and if
> you did have a great many names (or IPs) to query you might be better
> reading them from a file like so:
>
> xargs -L 1 host < names.txt
And dig(1) gives you a nice option for that, too:
$ dig -f FILE
Who's verbose now?
>> You can also use `+short' if dig(1)'s verbose output bothers you.
>
> That's a prime example of dig's verbosity! If you have to use such a
> clumsy verbose option to avoid getting a verbose screenful of output
> with a very low signal to noise ratio, then really there's no gain in
> convenience. Many of dig's options are similarly verbose, which is fine
> for scripting, but not for a casual command line query tool. A good Unix
> command's output should be concise by default, and a -v option should
> make it more verbose. Which is exactly how host behaves, of course.
[18:49][bas@superintendent:~]$ dig mx llamaselector.com
; <<>> DiG 9.6.0-APPLE-P2 <<>> mx llamaselector.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28022
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;llamaselector.com. IN MX
;; ANSWER SECTION:
llamaselector.com. 86284 IN MX 10 userland.llamaselector.com.
;; Query time: 20 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Tue Nov 24 18:49:32 2009
;; MSG SIZE rcvd: 60
[18:49][bas@superintendent:~]$ host -t mx llamaselector.com
llamaselector.com mail is handled by 10 userland.llamaselector.com.
You can describe dig(1)'s output as having a `low signal to noise ratio'
if you like, but personally I find much of that information quite useful.
Please, use whatever tool you like. I couldn't care less!
James Taylor
> James Taylor <use...@oakseed.demon.co.uk.invalid>:
>
>> Ben Shimmin wrote:
>>
>>> host(1) can do most common things, but dig(1) has some cool
>>> extras -- eg. it can do multiple queries in one swoop.
>>
>> Listing multiple names on a single command line is not necessarily much
>> better than querying for each one as needed while you research, and if
>> you did have a great many names (or IPs) to query you might be better
>> reading them from a file like so:
>>
>> xargs -L 1 host < names.txt
>
> And dig(1) gives you a nice option for that, too:
>
> $ dig -f FILE
>
> Who's verbose now?
That's nice, but it's an isolated example, and anyway the output would
be so verbose that it would scroll for miles and it wouldn't be easy to
make visual comparisons. In general, the "Unix way" is to use a
combination of small neat tools each of which does one thing well, not a
single untidily complex tool. I think dig's command line interface was
designed by committee - one that had little care for this culture.
> You can describe dig(1)'s output as having a `low signal to noise ratio'
> if you like, but personally I find much of that information quite useful.
It *can* be useful on occasion, but in the normal case you just want the
answer, and so adding a -v option for more info is better than having to
add a +short option for neater output.
I notice that dig +short gives such a brief output that in isolation
you'd not know what the output meant, so as script output it isn't
as useful as host's output which tells you which query gave the answer
on each line. For example, looking up google.com's IPs from here using
host -t a gives:
google.com has address 74.125.67.100
google.com has address 74.125.45.100
google.com has address 74.125.53.100
Whereas dig +short gives just:
74.125.67.100
74.125.45.100
74.125.53.100
and in a long list of scripted lookup results, you wouldn't be able to
distinguish which name gave which IPs. Is there any way to get dig to
say what each line means like host does it?
> Please, use whatever tool you like. I couldn't care less!
Just a friendly discussion!
Personally, the few times I've really needed to get my hands dirty
debugging a DNS issue, I've found that none of the lookup tools
give me everything I want to know. Wireshark is the only way.
--
James Taylor
Ben Shimmin
[...]
> For example, looking up google.com's IPs from here using
> host -t a gives:
>
> google.com has address 74.125.67.100
> google.com has address 74.125.45.100
> google.com has address 74.125.53.100
>
> Whereas dig +short gives just:
>
> 74.125.67.100
> 74.125.45.100
> 74.125.53.100
>
> and in a long list of scripted lookup results, you wouldn't be able to
> distinguish which name gave which IPs. Is there any way to get dig to
> say what each line means like host does it?
The best I can manage is:
[10:03][bas@rialto:~]$ dig google.com +noall +answer
google.com. 169 IN A 74.125.67.100
google.com. 169 IN A 74.125.45.100
google.com. 169 IN A 74.125.53.100
[...]
>
> Personally, the few times I've really needed to get my hands dirty
> debugging a DNS issue, I've found that none of the lookup tools
> give me everything I want to know. Wireshark is the only way.
Oh, I agree there.
James Taylor
> James Taylor <use...@oakseed.demon.co.uk.invalid>:
>
>> Is there any way to get dig to say what
>> each line means like host does it?
>
> The best I can manage is:
>
> [10:03][bas@rialto:~]$ dig google.com +noall +answer
> google.com. 169 IN A 74.125.67.100
> google.com. 169 IN A 74.125.45.100
> google.com. 169 IN A 74.125.53.100
That's pretty good, and there's no harm in having the TTL shown when it
doesn't cost anything in terms of extra lines of output. Pity about the
verbose options. I'd be tempted to alias that for frequent use. However,
there is a small discrepancy: On all the machines I've tried (Tiger,
Debian, and Ubuntu) the command produces something like:
$ dig google.com +noall +answer
; <<>> DiG 9.3.6-APPLE-P2 <<>> google.com +noall +answer
;; global options: printcmd
google.com. 235 IN A 74.125.45.100
google.com. 235 IN A 74.125.53.100
google.com. 235 IN A 74.125.67.100
I've tried adding +nocmd to the end of that, but it makes no difference, I
still get the version info. Then I found this in the manpage:
A global set of query options, which should be applied to all queries,
can also be supplied. These global query options must precede the first
tuple of name, class, type, options, flags, and query options supplied
on the command line. Any global query options (except the +[no]cmd
option) can be overridden by a query-specific set of query options.
Damn, why not the +nocmd option? How do I get the output you managed? Is
it only on Leopard that dig produces clean output, or were you using some
other flavour of Linux?
--
James Taylor
Gavin
<use...@oakseed.demon.co.uk.invalid> said:
> dig google.com +noall +answer
snowy:~ Gavsta$ dig google.com +noall +answer
; <<>> DiG 9.6.0-APPLE-P2 <<>> google.com +noall +answer
;; global options: +cmd
google.com. 42 IN A 74.125.45.100
google.com. 42 IN A 74.125.67.100
google.com. 42 IN A 74.125.53.100
is the reply in SL
Ben Shimmin
[...]
> That's pretty good, and there's no harm in having the TTL shown when it
> doesn't cost anything in terms of extra lines of output. Pity about the
> verbose options. I'd be tempted to alias that for frequent use. However,
> there is a small discrepancy: On all the machines I've tried (Tiger,
> Debian, and Ubuntu) the command produces something like:
>
> $ dig google.com +noall +answer
>
> ; <<>> DiG 9.3.6-APPLE-P2 <<>> google.com +noall +answer
> ;; global options: printcmd
> google.com. 235 IN A 74.125.45.100
> google.com. 235 IN A 74.125.53.100
> google.com. 235 IN A 74.125.67.100
>
> I've tried adding +nocmd to the end of that, but it makes no difference,
> I still get the version info. Then I found this in the manpage:
>
> A global set of query options, which should be applied to all queries,
> can also be supplied. These global query options must precede the first
> tuple of name, class, type, options, flags, and query options supplied
> on the command line. Any global query options (except the +[no]cmd
> option) can be overridden by a query-specific set of query options.
>
> Damn, why not the +nocmd option? How do I get the output you managed? Is
> it only on Leopard that dig produces clean output, or were you using some
> other flavour of Linux?
My output was from dig 9.3.2 on my Debian system. It looks like newer
versions perhaps behave differently.
Perhaps you could alias it to `dig $QUERY +noall +answer | tail -n +4'
or something!
Andrew Kemp
> James Taylor <use...@oakseed.demon.co.uk.invalid>:
>
> [...]
>
>> On all the machines I've tried (Tiger, Debian, and Ubuntu) the
>> command produces something like:
>>
>> $ dig google.com +noall +answer
>>
>> ; <<>> DiG 9.3.6-APPLE-P2 <<>> google.com +noall +answer
>> ;; global options: printcmd
>> google.com. 235 IN A 74.125.45.100
>> google.com. 235 IN A 74.125.53.100
>> google.com. 235 IN A 74.125.67.100
>>
>> I've tried adding +nocmd to the end of that, but it makes no
>> difference, I still get the version info. [...] How do I get the
>> output you managed? Is it only on Leopard that dig produces clean
>> output, or were you using some other flavour of Linux?
>
> My output was from dig 9.3.2 on my Debian system. It looks like newer
> versions perhaps behave differently.
>
> Perhaps you could alias it to `dig $QUERY +noall +answer | tail -n +4'
> or something!
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460209>
Using Snow Leopard:
$ dig google.com +noall +answer
; <<>> DiG 9.6.0-APPLE-P2 <<>> google.com +noall +answer
;; global options: +cmd
google.com. 231 IN A 74.125.53.100
google.com. 231 IN A 74.125.67.100
google.com. 231 IN A 74.125.45.100
but, on the same system...
$ dig +noall +answer google.com
google.com. 227 IN A 74.125.45.100
google.com. 227 IN A 74.125.53.100
google.com. 227 IN A 74.125.67.100
--
Drew
Ben Shimmin
> Ben Shimmin <b...@llamaselector.com> writes:
[...]
>> Perhaps you could alias it to `dig $QUERY +noall +answer | tail -n +4'
>> or something!
>
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460209>
>
> Using Snow Leopard:
>
> $ dig google.com +noall +answer
>
> ; <<>> DiG 9.6.0-APPLE-P2 <<>> google.com +noall +answer
> ;; global options: +cmd
> google.com. 231 IN A 74.125.53.100
> google.com. 231 IN A 74.125.67.100
> google.com. 231 IN A 74.125.45.100
>
> but, on the same system...
>
> $ dig +noall +answer google.com
> google.com. 227 IN A 74.125.45.100
> google.com. 227 IN A 74.125.53.100
> google.com. 227 IN A 74.125.67.100
As the guy on the Debian bug tracker says: strange.
I'm sure bizarre and unpredictable behaviour is another one of those
traits of good unix tools that James was talking about!