Re: diff for usr.bin/mg/fileio.c
Yes this also works for me.
On Thu, Apr 12, 2018 at 4:52 PM, Florian Obser <flor...@openbsd.org> wrote:
> On Tue, Apr 10, 2018 at 06:49:10PM +0200, Han Boetes wrote:
> > I got a problem report from Mark Willson:
> >
> > "I recently installed mg (via the Debian package) under WSL on
> Windows
> > 10.
> > I found that the 'backup-to-home-directory' option didn't work.
> >
> > The cause of this appears to be that getlogin under WSL returns NULL,
> > probably due to my use of wsltty to invoke bash. The patch below
> fixes
> > the issue for me:"
> >
> > [snip]
> > - if ((un = getlogin()) != NULL)
> > + if ((un = getenv("LOGNAME")) != NULL)
> > [snip]
> >
> > Which put me onto the track of what was going on. I found the
> > following in the Linux manpage:
> >
> > BUGS
> >Unfortunately, it is often rather easy to fool getlogin().
> > Sometimes
> >it does not work at all, because some program messed up the utmp
> > file.
> >Often, it gives only the first 8 characters of the login name.
> > The
> >user currently logged in on the controlling terminal of our
> > program
> >need not be the user who started it. Avoid getlogin() for
> > security-
> >related purposes.
> >
> >Note that glibc does not follow the POSIX specification and uses
> > stdin
> >instead of /dev/tty. A bug. (Other recent systems, like SunOS
> 5.8
> > and
> >HP-UX 11.11 and FreeBSD 4.8 all return the login name also when
> > stdin
> >is redirected.)
> >
> >Nobody knows precisely what cuserid() does; avoid it in portable
> > pro‐
> >grams. Or avoid it altogether: use getpwuid(geteuid())
> instead,
> > if
> >that is what you meant. Do not use cuserid().
> >
> > So I started looking at the code and rewrote it a bit, which I think
> > makes it more portable and removes a syscall in the process. I do
> > suspect this can be written even more elegantly, but didn't want to
> > rework the code too much.
> >
> > I also took the liberty to remove some whitespace.
> >
> >
> > Index: fileio.c
> > ===
> > RCS file: /cvs/src/usr.bin/mg/fileio.c,v
> > retrieving revision 1.104
> > @@ -703,7 +706,7 @@ expandtilde(const char *fn)
> > struct stat statbuf;
> > const char *cp;
> > char user[LOGIN_NAME_MAX], path[NFILEN];
> > - char*un, *ret;
> > + char*ret;
> > size_t ulen, plen;
> >
> > path[0] = '\0';
> > @@ -722,21 +725,21 @@ expandtilde(const char *fn)
> > return (NULL);
> > return(ret);
> > }
> > + pw = getpwuid(geteuid());
> > if (ulen == 0) { /* ~/ or ~ */
> > - if ((un = getlogin()) != NULL)
> > - (void)strlcpy(user, un, sizeof(user));
> > + if (pw != NULL)
> > + (void)strlcpy(user, pw->pw_name, sizeof(user));
> > else
> > user[0] = '\0';
> > } else { /* ~user/ or ~user */
> > memcpy(user, [1], ulen);
> > user[ulen] = '\0';
> > }
> > - pw = getpwnam(user);
> > if (pw != NULL) {
> > plen = strlcpy(path, pw->pw_dir, sizeof(path));
> > if (plen == 0 || path[plen - 1] != '/') {
> > if (strlcat(path, "/", sizeof(path)) >=
> > sizeof(path)) {
> > - dobeep();
> > + dobeep();
> > ewprintf("Path too long");
> > return (NULL);
> > }
>
> not quite, you leave pw unitialized in the else part.
>
> Lucas Gabriel Vuotto came up with a similar patch (to a different problem)
> back in 2017:
> https://marc.info/?l=openbsd-tech=149521389822841=2
>
> Which I subsequently slacked on, sorry!
>
> Here is a slightly tweaked version of Lucas' diff:
> - removed now unused un variable
> - geteuid() instead of getuid()
>
> Han, Lucas, does this work for you?
>
> diff --git fileio.c fileio.c
> index 0987f6f30de..339088f5e2d 100644
> --- file
diff for usr.bin/mg/fileio.c
I got a problem report from Mark Willson:
"I recently installed mg (via the Debian package) under WSL on Windows
10.
I found that the 'backup-to-home-directory' option didn't work.
The cause of this appears to be that getlogin under WSL returns NULL,
probably due to my use of wsltty to invoke bash. The patch below fixes
the issue for me:"
[snip]
- if ((un = getlogin()) != NULL)
+ if ((un = getenv("LOGNAME")) != NULL)
[snip]
Which put me onto the track of what was going on. I found the
following in the Linux manpage:
BUGS
Unfortunately, it is often rather easy to fool getlogin().
Sometimes
it does not work at all, because some program messed up the utmp
file.
Often, it gives only the first 8 characters of the login name.
The
user currently logged in on the controlling terminal of our
program
need not be the user who started it. Avoid getlogin() for
security-
related purposes.
Note that glibc does not follow the POSIX specification and uses
stdin
instead of /dev/tty. A bug. (Other recent systems, like SunOS 5.8
and
HP-UX 11.11 and FreeBSD 4.8 all return the login name also when
stdin
is redirected.)
Nobody knows precisely what cuserid() does; avoid it in portable
pro‐
grams. Or avoid it altogether: use getpwuid(geteuid()) instead,
if
that is what you meant. Do not use cuserid().
So I started looking at the code and rewrote it a bit, which I think
makes it more portable and removes a syscall in the process. I do
suspect this can be written even more elegantly, but didn't want to
rework the code too much.
I also took the liberty to remove some whitespace.
Index: fileio.c
===
RCS file: /cvs/src/usr.bin/mg/fileio.c,v
retrieving revision 1.104
@@ -703,7 +706,7 @@ expandtilde(const char *fn)
struct stat statbuf;
const char *cp;
char user[LOGIN_NAME_MAX], path[NFILEN];
- char*un, *ret;
+ char*ret;
size_t ulen, plen;
path[0] = '\0';
@@ -722,21 +725,21 @@ expandtilde(const char *fn)
return (NULL);
return(ret);
}
+ pw = getpwuid(geteuid());
if (ulen == 0) { /* ~/ or ~ */
- if ((un = getlogin()) != NULL)
- (void)strlcpy(user, un, sizeof(user));
+ if (pw != NULL)
+ (void)strlcpy(user, pw->pw_name, sizeof(user));
else
user[0] = '\0';
} else { /* ~user/ or ~user */
memcpy(user, [1], ulen);
user[ulen] = '\0';
}
- pw = getpwnam(user);
if (pw != NULL) {
plen = strlcpy(path, pw->pw_dir, sizeof(path));
if (plen == 0 || path[plen - 1] != '/') {
if (strlcat(path, "/", sizeof(path)) >=
sizeof(path)) {
- dobeep();
+ dobeep();
ewprintf("Path too long");
return (NULL);
}
small diff for acme-client that clarifies why the domain is not found.
I just added a new domain in my nameserver and then ran acme-client % sudo acme-client -D niets.boetes.org acme-client: domain niets.boetes.org not found So I assumed the dns was not yet in DNS. I waited a bit, checked the propagation of my new entry in DNS, double checked everything. Debugged, everything checked out fine. Still the same error. What was going on!? Ten minutes later I realised my error. This patch explains the problem so nobody can misunderstand the cause of the problem. diff --git a/usr.sbin/acme-client/main.c b/usr.sbin/acme-client/main.c index f8dc22c8756..bcc00c3bc35 100644 --- a/usr.sbin/acme-client/main.c +++ b/usr.sbin/acme-client/main.c @@ -98,7 +98,7 @@ main(int argc, char *argv[]) goto usage; if ((domain = domain_find(conf, argv[0])) == NULL) - errx(EXIT_FAILURE, "domain %s not found", argv[0]); + errx(EXIT_FAILURE, "domain %s not found in %s", argv[0], conffile); argc--; argv++; resulting in: % sudo ./acme-client -D niets.boetes.org acme-client: domain niets.boetes.org not found in /etc/acme-client.conf Please add me in your CC when replying to this email since I'm not subscribed to this list. # Han
Re: mg: [macro.c:41]: (error) Memory pointed to by 'lp1' is freed twice.
Hello Miod,
Will certainly do, thanks for your input!
Miod Vallat wrote:
I recently used cppcheck on mg and I got this message:
[macro.c:41]: (error) Memory pointed to by 'lp1' is freed twice.
Looking at the code:
/* free lines allocated for string arguments */
if (maclhead != NULL) {
for (lp1 = maclhead-l_fp; lp1 != maclhead; lp1 = lp2) {
lp2 = lp1-l_fp;
free(lp1);
}
free(lp1);
}
What do you guys think?
The
for (a; b; c)
d
construct is equivalent to
a;
while (b) {
d
c
}
so we have
lp1 = maclhead-l_fp;
while (lp1 != maclhead) {
lp2 = lp1-l_fp;
free(lp1);
lp1 = lp2;
}
free(lp1);
which looks correct to me. Replacing the second free(lp1) with
free(maclhead) should probably silence cppcheck, yet this should be
reported as a bug to the cppcheck developers.
Miod
# Han
--
\/A man without religion is like a fish without a bicycle.
)\__/(
|(oO)|
\||/
Ts (OO)
+vVv--vVv--+
mg: [macro.c:41]: (error) Memory pointed to by 'lp1' is freed twice.
I recently used cppcheck on mg and I got this message:
[macro.c:41]: (error) Memory pointed to by 'lp1' is freed twice.
Looking at the code:
/* free lines allocated for string arguments */
if (maclhead != NULL) {
for (lp1 = maclhead-l_fp; lp1 != maclhead; lp1 = lp2) {
lp2 = lp1-l_fp;
free(lp1);
}
free(lp1);
}
What do you guys think?
# Han
--
Please cc me, since I'm not subscribed.
Re: emacs fails to build after switching to 5.3
Jérémie Courrèges-Anglas wrote: Does that mean that *only* building with -DUNEXELF_DEBUG fails? If so, the problem is perhaps not that important... In that case I would not have reported a problem. I don't have a 64 bits host to repeat it. Please make it clear that the very last version of this file doesn't solve the issue. (Commit message: unexelf.c: Don't assume ElfW (Half) fits in int.) That commit was made to analyse the problem I reported, not to fix it. # Han
Re: emacs fails to build after switching to 5.3
Mark Kettenis wrote:
Date: Sat, 11 May 2013 04:41:03 +0200
From: Han Boetes h...@boetes.org
Han Boetes wrote:
I noticed emacs failed to build after switching to 5.3. I
discussed the matter with the emacs devs and they added some
debug code which is triggered by CFLAGS='-g3 -DUNEXELF_DEBUG' So
when it's building the main binary at Dumping under the name
emacs I get this output:
Incase anyone missed it: I'm always using the latest code from BZR.
And are you building/linking with -fno-pie -nopie?
Thanks for the heads up! That fixes the issue indeed.
% grep -i pie /usr/ports/editors/emacs/Makefile
LDFLAGS=-L${LOCALBASE}/lib -nopie
CFLAGS+=-fno-pie
# Han
Re: emacs fails to build after switching to 5.3
Han Boetes wrote: I noticed emacs failed to build after switching to 5.3. I discussed the matter with the emacs devs and they added some debug code which is triggered by CFLAGS='-g3 -DUNEXELF_DEBUG' So when it's building the main binary at Dumping under the name emacs I get this output: Incase anyone missed it: I'm always using the latest code from BZR. # Han
emacs fails to build after switching to 5.3
Hi, I noticed emacs failed to build after switching to 5.3. I discussed the matter with the emacs devs and they added some debug code which is triggered by CFLAGS='-g3 -DUNEXELF_DEBUG' So when it's building the main binary at Dumping under the name emacs I get this output: old_bss_index 25 old_bss_addr 0x63fca0 old_bss_size 0x73fd8 old_bss_offset 0x53fca0 new_bss_addr 0x4d313aa9000 new_data2_addr 0x63fca0 new_data2_size 0x13469360 new_data2_offset 0x53fca0 new_data2_incr 0x13469360 old_file_h-e_shoff 0x9a4258 Old section count 38 new_file_h-e_shoff 0x13e0d5b8 New section count 39 Segmentation fault gmake[1]: *** [bootstrap-emacs] Error 1 After which I got this comment back by email from the developer: new_bss_addr 0x4d313aa9000 That looks like the problem: OpenBSD's sbrk(0) is returning a huge value. src/unexelf.c isn't set up for that. Fixing this will require someone who knows ELF and OpenBSD fairly well, which alas is not me. He is refering to this file: http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/src/unexelf.c What needs to be done to fix this problem? # Han -- Please CC me since I am not subscribed to this list.
prong: keep your daemons alive and report if they are fataly wounded.
Hi, This is my idea of how to implement this functionality. Rather simple and transparent. If you like the idea but think you can make a better implementation feel free to make it.. Yes there are other implementations that can do about the same, but I wanted to write something the OpenBSD way. I hope the OpenBSD team at least likes the idea enough to implement something like this for one of the next releases. Download: http://homepage.boetes.org/software/prong.tgz The README: WHY PRONG? Since the introduction of the initscript in /etc/rc.d only one functionality has been missing: the option to automatically restart failed services and to report on them incase they won't come up again. Now for some useless info: Why prong? 1) It's one of my favourite bands. 2) The item that chucky is holding in his hands is a prong. It's used to prod on daemons! HOW IT WORKS: First read and then run ./setup, it creates symlinks for all running daemons in the prong.d directory. Then create a cronjob for prong. So add a line like */3 * * * * /etc/prong.d/prong with crontab -e to make prong run once in the three minutes. And then test everything by disabling a not so important daemon: /etc/rc.d/ntpd stop and notice how it automatically revives and that the name of the symlink is changed temporarily. WORKING WITH PRONG: The status command for prong is: ls -l /etc/prong.d/*.* All symlinks in this directory that start with d. are disabled. All symlinks in this directory that start with e. are enabled. All symlinks in this directory that start with f. have failed. So the idea is that if you want to temporarily prevent prong from restarting a daemon -- for maintainance purposes -- you'd: mv e.daemon d.daemon You can edit all scripts to do what you please. I think the only script you will really want to edit is the alert script. But do take a look at all scripts and read them and try to understand how they work. Start with prong itself. Notice that at the moment nothing is done with failed and disabled daemons? That's by design, but in your case you might want to change it. LICENSE: Public domain! Go away! Leave me alone! # Han
Re: prong: keep your daemons alive and report if they are fataly wounded.
Gilles Chehade gilles at poolp.org writes: Also, restarting a daemon that has crashed because of an exploit means you expose it again with maybe less luck next time (kindly reminded by mail Right, that's a valid point. In that case you'd only want an email to be sent. Either way, my script is from experience in production environments where daemons usually died for silly reasons which had nothing to do with break in attempts. A script like this is the difference between angry customers calling you out of bed in the middle of the night and waking up in the morning reading emails about services which stopped for no good reasons and nobody but me noticing while still being able to analyse and fix the problem. I'll ponder on your remarks and see if I come up with something. # Han
typos in stat(2)
I found these typos in the stat(2) manpage:
Index: sys/stat.2
===
RCS file: /cvs/src/lib/libc/sys/stat.2,v
retrieving revision 1.31
diff -u -p -r1.31 stat.2
--- sys/stat.2 17 Nov 2011 14:26:14 - 1.31
+++ sys/stat.2 10 Jul 2012 18:45:20 -
@@ -149,9 +149,9 @@ struct stat {
uid_t st_uid;/* user ID of the file's owner */
gid_t st_gid;/* group ID of the file's group */
dev_t st_rdev; /* device type */
-struct timespec st_atim; /* time of last access */
-struct timespec st_mtim; /* time of last data modification */
-struct timespec st_ctim; /* time of last file status change */
+struct timespec st_atime; /* time of last access */
+struct timespec st_mtime; /* time of last data modification */
+struct timespec st_ctime; /* time of last file status change */
off_t st_size; /* file size, in bytes */
int64_tst_blocks; /* blocks allocated for file */
u_int32_t st_blksize;/* optimal blocksize for I/O */
Typo st_mtim in stat manpage.
I found this mistake in the stat manpage:
Index: sys/stat.2
===
RCS file: /cvs/src/lib/libc/sys/stat.2,v
retrieving revision 1.31
diff -u -p -r1.31 stat.2
--- sys/stat.2 17 Nov 2011 14:26:14 - 1.31
+++ sys/stat.2 10 Jul 2012 18:45:20 -
@@ -149,9 +149,9 @@ struct stat {
uid_t st_uid;/* user ID of the file's owner */
gid_t st_gid;/* group ID of the file's group */
dev_t st_rdev; /* device type */
-struct timespec st_atim; /* time of last access */
-struct timespec st_mtim; /* time of last data modification */
-struct timespec st_ctim; /* time of last file status change */
+struct timespec st_atime; /* time of last access */
+struct timespec st_mtime; /* time of last data modification */
+struct timespec st_ctime; /* time of last file status change */
off_t st_size; /* file size, in bytes */
int64_tst_blocks; /* blocks allocated for file */
u_int32_t st_blksize;/* optimal blocksize for I/O */
# Han
taskset for smp
Hi, I just ran a script converting a bunch of files to mp3 and since I have a 8 core machine now I'd like to make my little script multi-threaded. So each resulting lame process will go to another core. When I ran the script I noticed that all processes ended up being run on the same processor. The next instance of the script also ran on the same processor. It was nu until I started a new shell they moved to another processor. So apparently each process and all it's children are being run on the same processor. Is that by design? Is there a setting which changes this behaviour so each child process goes to a random core? Would it be nice if there was a program like taskset which enables you to move processes to other cores? http://linuxcommand.org/man_pages/taskset1.html # Han -- Please CC me since I am not subscribed to this list.
Re: Simplification of the creation of unix socket directories in /etc/rc.
I still think this is a good patch so I bump it. Here is the original post: http://marc.info/?l=openbsd-techm=133288428820832w=2 # Han
Simplification of the creation of unix socket directories in /etc/rc.
If I'm not entirely mistaken this patch results in simpler and
more readable and straight forward code. The current code checks
for directories that can not exist since they were removed a few
lines before and then creates them.
Index: rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.392
diff -u -p -r1.392 rc
--- rc 28 Jul 2011 19:09:16 - 1.392
+++ rc 27 Mar 2012 21:34:00 -
@@ -183,30 +183,6 @@ make_keys()
ssh-keygen -A
}
-# create Unix sockets directories for X if needed and make sure they have
-# correct permissions
-setup_X_sockets()
-{
- if [ -d /usr/X11R6/lib ]; then
- for d in /tmp/.X11-unix /tmp/.ICE-unix ; do
- if [ -d $d ]; then
- if [ `ls -ld $d | cut -d' ' -f4` \
- != root ]; then
- chown root $d
- fi
- if [ `ls -ld $d | cut -d' ' -f1` \
- != drwxrwxrwt ]; then
- chmod 1777 $d
- fi
- elif [ -e $d ]; then
- echo Error: $d exists and isn't a directory.
- else
- mkdir -m 1777 $d
- fi
- done
- fi
-}
-
# End subroutines
stty status '^T'
@@ -442,14 +418,18 @@ fi
echo clearing /tmp
-# prune quickly with one rm, then use find to clean up /tmp/[lq]*
+# Prune quickly with one rm, then use find to clean up /tmp
# (not needed with mfs /tmp, but doesn't hurt there...)
(cd /tmp rm -rf [a-km-pr-zA-Z]*)
(cd /tmp
find . ! -name . ! -name lost+found ! -name quota.user \
! -name quota.group -execdir rm -rf -- {} \; -type d -prune)
-setup_X_sockets
+# Create Unix socket directories for X if needed.
+if [ -d /usr/X11R6/lib ]; then
+mkdir -m 1777 /tmp/.{X11,ICE}-unix
+fi
+
[ -f /etc/rc.securelevel ] . /etc/rc.securelevel
if [ X${securelevel} != X ]; then
# Han
[trentb...@gmail.com: Re: mg: The Delete key should delete the character to the right of the cursor]
This patch for mg is suggested by the debian team to add support for the del key. Seems like a nobrainer and also works in OpenBSD. Sorry for the long message but I want to give credit where credit is due. - Forwarded message from Trent W. Buck trentb...@gmail.com - Date: Thu, 8 Mar 2012 11:14:46 +1100 From: Trent W. Buck trentb...@gmail.com To: Han Boetes h...@mijncomputer.nl Subject: Re: mg: The Delete key should delete the character to the right of the cursor Han, How do you feel about applying this change upstream (of me/Debian)? Ref. http://bugs.debian.org/661732 Date: Wed, 29 Feb 2012 20:28:27 +0100 From: Peter De Wachter pdewa...@gmail.com To: Debian Bug Tracking System sub...@bugs.debian.org Subject: Bug#661732: mg: The Delete key should delete the character to the right of the cursor Currently mg doesn't have a binding for the Delete key. Debian Policy 9.8 says that it should. The attached two-line patch fixes this. --- mg-20110905.orig/ttykbd.c 2012-02-29 11:35:35.0 +0100 +++ mg-20110905/ttykbd.c2012-02-29 12:25:59.521218562 +0100 @@ -55,6 +55,8 @@ dobindkey(fundamental_map, scroll-up, key_npage); if (key_ppage) dobindkey(fundamental_map, scroll-down, key_ppage); + if (key_dc) + dobindkey(fundamental_map, delete-char, key_dc); #endif /* FKEYS */ #ifndefNO_STARTUP - End forwarded message - # Han
Re: request for the inclusion of the pcap-filter manpage
Lawrence Teo wrote: On Mon, Mar 05, 2012 at 12:43:07AM +0100, Ingo Schwarze wrote: http://www.manpagez.com/man/7/pcap-filter/ http://www.tcpdump.org/release/libpcap-1.2.1.tar.gz Please consider adding it to the distribution. From cursory inspection, it looks like OpenBSD is using a fork of libpcap 0.4 or 0.5, selectively including later tcpdump.org additions, but not tracking upstream development closely, so including parts of the libpcap 1.2.1 manual would seem wrong. Yes, the last selective sync was with libpcap 0.9.4 in 2006. On a related note, I sent a diff to tech@ back in November 2011 that imports a number of core functions from libpcap 1.2.0 to libpcap in base. It makes it easier to port programs that need the newer libpcap (like Snort 2.9.x) to OpenBSD. The diff could use some testing if anyone's interested. :) http://marc.info/?l=openbsd-techm=132029368027597w=2 My remark was based on a late night thinko. Indeed libpcap included with openbsd is rather old. This patch seems to be the proper answer. # Han
request for the inclusion of the pcap-filter manpage
The current libpcap distribution contains the pcap-filter manpage which in my opinion is a very useful manpage for the use of tcpdump. http://www.manpagez.com/man/7/pcap-filter/ http://www.tcpdump.org/release/libpcap-1.2.1.tar.gz Please consider adding it to the distribution. # Han
Re: Small pkill enhancement
Not to jhijack the thread but to show another -- more generic way -- of dealing with apps that fail silently: This changes the prompt $ to red incase the $? return value of the previous process returned non-zero. red=$(printf '\e[31m') export PS1='\[\e[0;36m\]\w\[\e[01m\]\[\e[30m\]$([ $? -eq 0 ]||printf $red)\$\[\e[0m\] ' # Han
Re: Design of spamd
Kevin Chadwick wrote: On Wed, 30 Nov 2011 20:00:27 +0100 Han Boetes wrote: So for some reason passtime is ignored on my machine. I've tested this with telnet quite extensively. And after 3,4,5 attempts in a minute or so the address is whitelisted. What version of OpenBSD are you running? 5.0 Does it do this without your addon scripts? How would that affect it? It merely blacklists a few entries. # Han
Re: nc port scan, aka udp noise maker.
You can use them but it is pointless. Brynet wrote: I think this was a feature, right? :-) Index: netcat.c === RCS file: /cvs/src/usr.bin/nc/netcat.c,v retrieving revision 1.101 diff -u -p -u -r1.101 netcat.c --- netcat.c 21 Jun 2011 17:31:07 - 1.101 +++ netcat.c 9 Sep 2011 07:01:05 - @@ -264,6 +264,8 @@ main(int argc, char *argv[]) errx(1, cannot use -p and -l); if (lflag zflag) errx(1, cannot use -z and -l); + if (uflag zflag) + errx(1, cannot use -u and -z); if (!lflag kflag) errx(1, must use -l with -k); # Han
Re: invalid link in ath(4) manpage
Jason McIntyre wrote: fixed, and an identical link in uath(4) removed too. Might I suggest pulling all sourcefiles through a linkchecker? # Han
Re: mg:join-line
Kjell Wooding wrote: I might add an undo boundary around the whole thing (I note emacs doesn't do this properly, at least on the version I have here)... Undoing join-line works fine with the emacs version I am using here. Built 2 days ago, from git. ~% emacs --version GNU Emacs 24.0.50.1 # Han
Re: ld.so fix for empty LD_PRELOAD
Mark Kettenis wrote: From: Marco Peereboom sl...@peereboom.us I kind of disagree with you mark and I think that the diff makes sense. FWIW, I feel too strongly about this. If you want to check it check it properly. For example use stat to see if LD_PRELOAD contains an existing file or use file to see if it's really a library. But checking if LD_PRELOAD only contains an empty string seems like a non check. Would you also check if it contained a space or two spaces? Actually there is no need to check since if the file is not a valid library the result would be an error which the user has to debug. Something about giving users enough rope... # Han
set loginterface [if|ifgroup|none|all]
Hi,
I took a leap of faith and discovered some options not mentioned
in pf.conf(5). What do you think of this patch?
Index: share/man/man5/pf.conf.5
===
RCS file: /cvs/src/share/man/man5/pf.conf.5,v
retrieving revision 1.476
diff -u -r1.476 pf.conf.5
--- share/man/man5/pf.conf.519 May 2010 13:51:37 - 1.476
+++ share/man/man5/pf.conf.516 Dec 2010 09:49:23 -
@@ -1057,15 +1057,15 @@
.Pp
.Dl # pfctl -s info
.Pp
-In this example
+You can set on which interfaces
.Xr pf 4
-collects statistics on the interface named dc0:
+collects statistics with:
.Pp
-.Dl set loginterface dc0
+.Dl set loginterface [if|ifgroup|none|all]
.Pp
-One can disable the loginterface using:
+For example, you can enable logging both bge0 and bge1 with:
.Pp
-.Dl set loginterface none
+.Dl set loginterface bge
.It Ar set optimization
Optimize state timeouts for one of the following network environments:
.Pp
@@ -2608,7 +2608,7 @@
[ optimization [ default | normal | high-latency |
satellite | aggressive | conservative ] ]
[ limit ( limit-item | { limit-list } ) ] |
- [ loginterface ( interface-name | none ) ] |
+ [ loginterface ( interface-name | interface-group | none
| all ) ] |
[ block-policy ( drop | return ) ] |
[ state-policy ( if-bound | floating ) ]
[ state-defaults state-opts ]
# Han
Re: fortune(6): chess help required
Yes, I have something to say about it: A Dutch master Tim Krabe has published quite a bit about the shortest game: http://www.xs4all.nl/~timkr/records/recordstxt.htm#Shortest%20game So now the question is: do you still want to publish this shortest game? And if you do I would publish it with modern chess notation rather than the old fashioned chess notation which is no longer in use in britain, the only country that did use it. # Han
{Spam?} Re: [patch] less: filename globbing/expansion
Nicholas Marriott wrote: On Sat, Apr 03, 2010 at 03:37:46PM +1030, Matthew Haub wrote: We no longer track upstream less(1). The last sync was 7 years ago. Yes, but is that for a reason or just because nobody has updated it? Because everybody uses w3m to replace less and lynx nowadays. # Han
Re: enhancing i386 mbr.S
Giuseppe Magnotta wrote: I would like to submit a patch that will enhance the mbr of i386 machines. Could you be so kind as to provide us with a unified patch? You can make one with: cvs diff -u Thanks! # Han
Re: typo /cvs/src/sbin/ping/ping.c
Good finds. To make them even better make sure your mta doesn't wrap the lines. ;-) Brad Tilley wrote: # cvs diff -Nup ping.c Index: ping.c === RCS file: /cvs/src/sbin/ping/ping.c,v retrieving revision 1.85 diff -N -u -p ping.c --- ping.c 15 Dec 2009 21:09:43 - 1.85 +++ ping.c 23 Dec 2009 01:16:59 - @@ -1085,7 +1085,7 @@ pr_icmph(struct icmp *icp) (void)printf(Destination Net Unreachable for TOS\n); break; case ICMP_UNREACH_TOSHOST: - (void)printf(Desination Host Unreachable for TOS\n); + (void)printf(Destination Host Unreachable for TOS\n); break; case ICMP_UNREACH_FILTER_PROHIB: (void)printf(Route administratively prohibited\n); # Han
Re: kernel make file doesn't have dependency for bsd for the install target
Anathae E. Townsend wrote: Han Boetes wrote on Sunday, October 18, 2009 1:51 PM I'm not a developer, and I don't speak for them, but I suspect that install does not depend on bsd for specific reasons. First guess, as make takes a while to run, and make install is meant to be followed immediately with '#shutdown -r now', make install is not meant to be used in a 'batch'. I doubt that a dependency on any of the kernels built with make will be added. Yes, and I didn't like my solution either. I got something here that tests if bsd is there before actually attempting to install which works ok. Since nobody responded I kept it to myself. # Han
kernel make file doesn't have dependency for bsd for the install target
Hi,
I just ran tried to install the kernel and ran:
make depend
make install
Since I forgot running make and since there is no dependency for
bsd the target removed my old kernel without installing the new
one.
How about this patch for the i386 target?
cvs server: Diffing .
Index: Makefile.i386
===
RCS file: /cvs/src/sys/arch/i386/conf/Makefile.i386,v
retrieving revision 1.51
diff -u -p -r1.51 Makefile.i386
--- Makefile.i386 11 Jan 2009 21:02:03 - 1.51
+++ Makefile.i386 18 Oct 2009 19:48:41 -
@@ -190,7 +190,7 @@ locore.o: ${I386}/i386/locore.s assym.h
MACHINE_NAME!= uname -n
install: install-kernel-${MACHINE_NAME}
.if !target(install-kernel-${MACHINE_NAME}})
-install-kernel-${MACHINE_NAME}:
+install-kernel-${MACHINE_NAME}: bsd
rm -f /obsd
ln /bsd /obsd
cp bsd /nbsd
# Han
strtime.3 inconsistency
Hi, In the rest of the document maxsize is used so I this one has to be changed to maxsize as well. Index: strftime.3 === RCS file: /cvs/src/lib/libc/time/strftime.3,v retrieving revision 1.22 diff -u -p -r1.22 strftime.3 --- strftime.3 31 May 2007 19:19:34 - 1.22 +++ strftime.3 9 Sep 2009 03:42:33 - @@ -240,7 +240,7 @@ Note that while this implementation of will always NUL terminate .Fa buf , other implementations may not do so when -.Fa maxsiz +.Fa maxsize is not large enough to store the entire time string. The contents of .Fa buf # Han
Re: tmux(1) bugfix
Simon Nicolussi wrote: one of the recent changes to tmux has the unintented side-effect that all clients are being redrawn every second. This is visible for people with slow terminals and furthermore makes copying text with the mouse quite tricky. Here's a trivial fix: You will also notice this problem on fast terminals with a fast connection if you press shift and then attempt to cp. Thanks for your patch. /me pokes NicM # Han
