Dima and /me recently started weeding out white space at end of line for
the man pages. I want to widen the weeding to include as much files as
possible under /usr/src. We currently have 280kbytes (yes, more than a
quarter meg) sitting there; that's counting only the spaces and tabs at
EOL, not the whole line.
I've got a perl script that removes the white space at EOL
automagically, but before I break anything I would like to ask the
combined hacker wisdom if you can think of any occasion where whitespace
at EOL would be significant and must not be removed. The script already
skips non-plain and binary files (as detected by perl's -T/-B file test
operators).
The only case I can think of right now is a file where we have a
backslash followed by whitespace followed by EOL. Removing the
whitespace may change semantics if the file type supports the notion of
backslash continuation lines, eg. a shell script with
echo foo\ <- with a space after the \
bar
in it, which would turn to echo "foobar" instead of echo "foo " and
executing bar.
However, C source should be safe to just s/[ \t]+$//g, I can't think of
a valid way to have {backslash whitespace EOL} in C source outside of
comments (where the whitespace can safely be removed because the backslash
has no continuation semantics.)
Regards,
Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Please do not do this to the .[ch] files. It makes diffs to stable harder.
You may not know this, but in the early history of the "new" CVS tree
(ie. /home/ncvs vs. /home/cvs) with the 4.4BSD Lite code someone did this
(including pulling files off the vendor branch). In the end this has
really irritated *many* a FreeBSD developer. Please leave such cleanup to
when people are in the files cleaning up other style nits so we don't
have 1 million commits, each taking care of just one point of style(9).
And as you mentioned in your email, there are cases where you could
change the semantics. If one is doing a few files at a time, they can
catch the semantic changes. When doing it in-mass using a script, you
will miss at least one.
--
-- David (obr...@FreeBSD.org)
Maybe I'm just plain dim today (I will add a beer to rectify this situation
at first convenience..) but what is so bad about some trailing whitespace
that a massive commit-a-thlon is called for?
just wondering,
Wilko
--
| / o / / _ Arnhem, The Netherlands email: wi...@FreeBSD.org
|/|/ / / /( (_) Bulte "Youth is not a time in life, it is a state of mind"
On Sun, Jul 15, 2001 at 11:19:57AM -0700, David O'Brien wrote:
# On Sun, Jul 15, 2001 at 03:59:41PM +0200, Jens Schweikhardt wrote:
# > Dima and /me recently started weeding out white space at end of line for
# > the man pages. I want to widen the weeding to include as much files as
# > possible under /usr/src.
#
# Please do not do this to the .[ch] files. It makes diffs to stable harder.
I see. Dima suggested in private email that I/we MFC such changes
relatively fast in order to avoid that; of course this would be done
only after md5 "approval" of the binaries.
# You may not know this, but in the early history of the "new" CVS tree
# (ie. /home/ncvs vs. /home/cvs) with the 4.4BSD Lite code someone did this
# (including pulling files off the vendor branch). In the end this has
# really irritated *many* a FreeBSD developer. Please leave such cleanup to
# when people are in the files cleaning up other style nits so we don't
# have 1 million commits, each taking care of just one point of style(9).
OK, then I think it's best to tell developers@ about my script in
freefall:~schweikh/bin/ws-at-eol which by default will only print the
names of the files and optionally the line numbers/lines. Committers are
encouraged to make use of it as they see fit. Folks, please remember to
make separate commits for content changes and whitespace changes.
$ ws-at-eol
usage: ws-at-eol [options] directory ...
Find whitespace at end-of-line in text files.
Options:
--help show this help text
--remove remove whitespace at EOL using in-place editing
--showlines print lines that have whitespace at EOL to stdout.
EOL is marked by a $ sign, followed by a sequence
of s and t characters for each space or tab.
Examples:
ws-at-eol /usr/src/share/man
Regards,
Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
To Unsubscribe: send mail to majo...@FreeBSD.org
> David et al,
>
> On Sun, Jul 15, 2001 at 11:19:57AM -0700, David O'Brien wrote:
> # On Sun, Jul 15, 2001 at 03:59:41PM +0200, Jens Schweikhardt wrote:
> # > Dima and /me recently started weeding out white space at end of line for
> # > the man pages. I want to widen the weeding to include as much files as
> # > possible under /usr/src.
> #
> # Please do not do this to the .[ch] files. It makes diffs to stable harder.
>
> I see. Dima suggested in private email that I/we MFC such changes
> relatively fast in order to avoid that; of course this would be done
> only after md5 "approval" of the binaries.
Whether you MFC it or not, you're going to cause a lot of commit log
pollution. I don't think it's worth the hassle when all we're talking
about is trailing whitespace.
Mike "Silby" Silbersack
:
:On Sun, 15 Jul 2001, Jens Schweikhardt wrote:
:> I see. Dima suggested in private email that I/we MFC such changes
:> relatively fast in order to avoid that; of course this would be done
:> only after md5 "approval" of the binaries.
:
:Whether you MFC it or not, you're going to cause a lot of commit log
:pollution. I don't think it's worth the hassle when all we're talking
:about is trailing whitespace.
:
Not only commitlog pollution, but also repository file growth, and wasted
bandwidth from those cvsuping the changes. My cvsup of the repository took
~4 times as long when the changes were made to the man pages. You said it
would save ~250K in the source tree. What's it do to the size of the whole
repository?
--
dsch...@tumbolia.com
Bipedalism is only a fad.
Also note that your reason for changing this is the disk space consumed
by the extra blanks. You're going to be combatting that by using up
disk space for patches (at least as far as my systems are concerned,
because I cvsup the CVS tree and not any specific release).
># Please leave such cleanup to
># when people are in the files cleaning up other style nits so we don't
># have 1 million commits, each taking care of just one point of style(9).
>
>OK, then I think it's best to tell developers@ about my script in
>freefall:~schweikh/bin/ws-at-eol which by default will only print the
>names of the files and optionally the line numbers/lines. Committers are
>encouraged to make use of it as they see fit. Folks, please remember to
>make separate commits for content changes and whitespace changes.
I am not in favor of a generic sweep to remove blank space, but the
script will be useful to use when working on some source for other
reasons. Thanks.
--
Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute or dro...@rpi.edu
*sigh* Are we now a hostage to CVSup times? Put it in cron and do it at
3am when you don't really care how long it takes. You would not have
survived the `sup' days if you think CVSup takes a long time. I can only
laugh at the "wasted bandwidth" comment. Any idea how much BW was being
taken up by Napster related traffic until a month ago?? CVSup, with its
low BW design of only sending diffs, pales in comparison.
--
-- David (obr...@FreeBSD.org)
You use emacs, don't you?
8-) 8-)
-- Terry
No, vi. My first experiences with Unix (SysV.2) were in the days that
Emacs was considered anti-social (on 8MB memory machines with 68020 CPUs).
W/
--
| / o / / _ Arnhem, The Netherlands email: wi...@FreeBSD.org
|/|/ / / /( (_) Bulte "Youth is not a time in life, it is a state of mind"
To Unsubscribe: send mail to majo...@FreeBSD.org
What, you mean you *haven't* run emacs on a Sun-3/50 with 4 Mbytes? :-)
Steinar Haug, Nethelp consulting, sth...@nethelp.no
No. I did run SunOS 3.5 on them but that was without Emacs. The 3/50 was
an upgrade of our 2/120 ;-) Ever tried compiling X on a 2/120? :)
W/
--
| / o / / _ Arnhem, The Netherlands email: wi...@FreeBSD.org
|/|/ / / /( (_) Bulte "Youth is not a time in life, it is a state of mind"
To Unsubscribe: send mail to majo...@FreeBSD.org
What does vi vs. emacs have to do with it?
--
-- David, a Vi user.
It's even not fun with these:
ticso@cicely41:~> dmesg | head
NetBSD 1.5V (CICELY41) #1: Sat May 19 21:52:45 CEST 2001
ti...@cicely41.cicely.de:/net/10.1.1.22/var/d21/NetBSD/src/sys/arch/sun3/compile/CICELY41
Model: sun3 60
fpu: mc68881
total memory = 24576 KB
avail memory = 21888 KB
using 166 buffers containing 1328 KB of memory
mainbus0 (root)
obio0 at mainbus0
zsc0 at obio0 addr 0x0 ipl 6: (softpri 3)
ticso@cicely41:~> uptime
9:48PM up 43 days, 6:42, 3 users, load averages: 0.18, 0.12, 0.09
I also own two 3/50 but 4M is not realy much today.
But now that NetBSD has official support for sun2 Machines ;)
--
B.Walter COSMO-Project http://www.cosmo-project.de
ti...@cicely.de Usergroup in...@cosmo-project.de
> On Mon, Jul 16, 2001 at 09:42:22AM -0700, Terry Lambert wrote:
> > Wilko Bulte wrote:
> > > Maybe I'm just plain dim today (I will add a beer to rectify this situation
> > > at first convenience..) but what is so bad about some trailing whitespace
> > > that a massive commit-a-thlon is called for?
> > >
> > > just wondering,
> > > Wilko
> >
> > You use emacs, don't you?
>
> What does vi vs. emacs have to do with it?
It's probably one of those rumours that Emacs likes playing smart and $
adding whitespace to the end of wrapped lines. Lies, damn lies. $
$
-giorgos $
$
(a happy emacs user who also feels comfortable with vi, joe, pico, whatever) $
The beer.
--
"Castles are sacked in war, Chieftains are scattered far, Truth is a
fixed star, Eileen aroon!" -- Gerald Griffin
______________________________________________________________________
Charles Shannon Hendrix s h a n n o n @ w i d o m a k e r . c o m
Got it in one... $
-- Terry $