Reapply 4cea05a273:
Make sh(1) recognize the default $HOME. By default /home
is a symlink; without this change, when you log in, sh(1)
won't realize the current directory (eg '/usr/home/test')
is the same as $HOME ('/home/test').
/home is no longer a symlink by default, but new users may be added on
systems that started out with an earlier version of FreeBSD (and still
have /home as a symlink) or admins may do so.
This test is not particularly expensive, so just restore it.
Suggested by: danfe, brooks
Since FreeBSD 14.0, user directories are created directly under /home.
This check should no longer be needed.
This reverts commit 4cea05a273.
Signed-off-by: Collin Funk <collin.funk1@gmail.com>
Pull-request: https://github.com/freebsd/freebsd-src/pull/1102
Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl script.
Sponsored by: Netflix
For $reason mobaxterm default on sending unusual sequence from home/del
key, which makes libedit unabel to catch them and bind them correctly.
mobaxterm seems popular on the windows environment, so add proper
keybinding to default shrc configuration so it works out of box.
Reported by: lme
Somehow we end up having 2 definition of the same .shrc in the source
tree, both of them should have been updated.
A batter fix would be to only keep one copy of the same file. but that
would be for another commit
Reported by: lme
there's no need to even mention it in shell rc files. Not that it's wrong;
just pointless and somewhat misleading.
Reviewed by: jilles
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D18809
is a symlink; without this change, when you log in, sh(1)
won't realize the current directory (eg '/usr/home/test')
is the same as $HOME ('/home/test').
Reviewed by: jilles
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D18775
prompt, so it looks just like the tcsh(1) one when you uncomment it.
Reviewed by: jilles
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D18673
the terminal work properly out of the box when logging over a serial
line, which is quite important for the user experience on boards like
Raspberry Pi. It doesn't affect cases where the terminal size is
already non-zero, such as SSH or vt(4) sessions.
Note that this doesn't handle a scenario pointed out by rgrimes@:
when the terminal is resized after login, the terminal size won't
get updated even after logging out and back in.
Reviewed by: imp
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D10642
sh has defaulted to 'set -o emacs' since FreeBSD 9.0. Therefore, do not set
this again in .shrc, since that only serves to prevent invocations like
'sh -o vi' and 'sh +o emacs' to have the intended effect.
PR: 215958
Submitted by: Andras Farkas
MFC after: 1 week
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
update paths; and include everything in the "base" distribution.
The "games" distribution being optional made sense when there were more
games and we had small disks; but the "games-like" games were moved into
the ports tree a dozen years ago and the remaining "utility-like" games
occupy less than 0.001% of my laptop's small hard drive. Meanwhile every
new user is confronted by the question "do you want games installed" when
they they try to install FreeBSD.
The next steps will be:
2. Removing punch card (bcd, ppt), phase-of-moon (pom), clock (grdc), and
caesar cipher (caesar, rot13) utilities. I intend to keep fortune, factor,
morse, number, primes, and random, since there is evidence that those are
still being used.
3. Merging src/games into src/usr.bin.
This change will not be MFCed.
Reviewed by: jmg
Discussed at: EuroBSDCon
Approved by: gjb (release-affecting changes)
Since I've committed this I've receieved roughly an equal
amount of email thanking me for making this change
and asking me to revert it.
I've resisted making this change because
new users tend to prefer less over more
and these users are the least likely to know
how to change the PAGER on their own.
Requested by: many
Objected to: just as many
Decision made by: core
Approved by: cperciva
MFC after: 3 days
POSIX says an empty entry in CDPATH shall not result in the new directory
being printed, while any non-empty entry shall result in the new directory
being printed, including ".". Therefore, the value of CDPATH should almost
always start with a colon, not dot and colon.
Our sh does not print the name for empty entries as well as "." entries.
MFC after: 1 week
Right now syscons(4) uses a cons25-style terminal emulator. The
disadvantages of that are:
- Little compatibility with embedded devices with serial interfaces.
- Bad bandwidth efficiency, mainly because of the lack of scrolling
regions.
- A very hard transition path to support for modern character sets like
UTF-8.
Our terminal emulation library, libteken, has been supporting
xterm-style terminal emulation for months, so flip the switch and make
everyone use an xterm-style console driver.
I still have to enable this on i386. Right now pc98 and i386 share the
same /etc/ttys file. I'm not going to switch pc98, because it uses its
own Kanji-capable cons25 emulator.
IMPORTANT: What to do if things go wrong (i.e. graphical artifacts):
- Run the application inside script(1), try to reduce the problem and
send me the log file.
- In the mean time, you can run `vidcontrol -T cons25' and `export
TERM=cons25' so you can run applications the same way you did before.
You can also build your kernel with `options TEKEN_CONS25' to make all
virtual terminals use the cons25 emulator by default.
Discussed on: current@
these days, and the average user expects ^A and arrow keys to work, however
if they know nothing of editing modes, they will think sh(1) just sucks. It
is likely that because of defaults on most systems and with most shells that
anyone who actually wants vi(1) editing mode will have 'set -o vi'. This
won't affect existing accounts, this way, of course. Only accounts with
.shrc from new etc/skel will be affected. This is much better than making
the change in sh(1).
