1. A serious bug introduced 3 1/2 months ago (approx) (rev 1.116) which
broke all but the simple cases of ~ expansions is fixed (amazingly,
given the magnitude of this problem, no-one noticed!)
2. An ancient bug (probably from when ~ expansion was first addedin 1994, and
certainly is in NetBSD-6 vintage shells) where ${UnSeT:-~} (and similar)
does not expand the ~ is fixed (note that ${UnSeT:-~/} does expand,
this should give a clue to the cause of the problem.
3. A fix/change to make the effects of ~ expansions on ${UnSeT:=whatever}
identical to those in UnSeT=whatever In particular, with HOME=/foo
${UnSeT:=~:~} now assigns, and expands to, /foo:/foo rather than ~:~
just as VAR=~:~ assigns /foo:/foo to VAR. Note this is even after the
previous fix (ie: appending a '/' would not change the results here.)
It is hard to call this one a bug fix for certain (though I believe it is)
as many other shells also produce different results for the ${V:=...}
expansions than they do for V=... (though not all the same as we did).
POSIX is not clear about this, expanding ~ after : in VAR=whatever
assignments is clear, whether ${U:=whatever} assignments should be
treated the same way is not stated, one way or the other.
4. Change to make ':' terminate the user name in a ~ expansion in all cases,
not only in assignments. This makes sense, as ':' is one character that
cannot occur in user names, no matter how otherwise weird they become.
bash (incl in posix mode) ksh93 and bosh all act this way, whereas most
other shells (and POSIX) do not. Because this is clearly an extension
to POSIX, do this one only when not in posix mode (not set -o posix).
Currently testing ~user is too much effort to contemplate (other than
assuming that it works in order to verify that it works...) so only bare ~
is being tested for now. Maybe someday...
Right now (@ time of commit), this new test is expected to fail, as ~
expansions are horribly badly broken (have been for months, some forms
for much longer) in all but the simplest of uses. Fix for that coming
very soon.
Print vm_aslr_delta_mmap from 'struct vmspace'.
Print the WANTVA bit of 'flags' from 'struct vm_map'.
Replace %x with %#x, this improves readability of hex vs dec numbers.
Sponsored by <The NetBSD Foundation>
argument. This bug was added in rev. 1.68.
- Don't check neither VTEICR nor VTEICS same as Linux. It seems that both
registers can't be used to check which MSI-X vector is triggered. A bit is
set on very low probability and the bit location is incorrect. Is this an
errata?
because those medias are not in the spec.
- Add 2.5GBASE-T and 5GBASE-T support. Tested with X550-T1.
Example:
ixg0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=fff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
capabilities=fff80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx>
capabilities=fff80<TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6,LRO>
enabled=7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
enabled=7ff80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx>
enabled=7ff80<TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
ec_capabilities=7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
ec_enabled=7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
address: a0:36:9f:b0:f5:b0
media: Ethernet 2.5GBASE-T full-duplex
status: active
supported Ethernet media:
media 10Gbase-T
media 10Gbase-T mediaopt full-duplex
media 1000baseT
media 1000baseT mediaopt full-duplex
media 100baseTX
media 100baseTX mediaopt full-duplex
media 2.5GBASE-T mediaopt full-duplex
media 5GBASE-T mediaopt full-duplex
media autoselect
inet 172.16.0.1/24 broadcast 172.16.0.255 flags 0x0
inet6 fe80::a236:9fff:feb0:f5b0%ixg0/64 flags 0x0 scopeid 0x1
