Re: Absolute pathnames similar to expand-cmd-path

Re: Absolute pathnames similar to expand-cmd-path

[Peter Stephenson]

On Fri, 28 Jan 2011 22:17:24 +0000
Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> This tickles cursor positioning annyonances in undo.

An example of what I'm talking about that doesn't need user-defined
widgets:

- type 'echo foo bar'
- move the cursor to 'f'
- delete the next word (Esc d in Emacs mode)
- undo.

You find the cursor at the end of the line.  I contend that you'd
expect it to be on the f.  OK, I state as a fact that that's what I'd
expect and it seems to me the only natural expectation.

We don't update the last cursor position on movement commands, only on
changes.  I *think* the following simple change makes things much
better, to wit, after an undo you get taken back to the cursor
position immediately before the change being undone, rather than where
you made the change before that.

Please say if you see any more oddities with undo, I've been wondering
about this for years and have only just started trying to get to grips
with the undo system.

CVS is still down.  It sounds like it's probably time to move to git
after the next stable release, nobody's suggested replacing it with an
even more trendy system yet...

--- ../zsh-git/zsh/Src/Zle/zle_utils.c	2010-10-05 22:24:01.000000000 +0100
+++ Src/Zle/zle_utils.c	2011-01-29 23:08:45.000000000 +0000
@@ -1085,8 +1085,10 @@ mkundoent(void)
     struct change *ch;
 
     UNMETACHECK();
-    if(lastll == zlell && !ZS_memcmp(lastline, zleline, zlell))
+    if(lastll == zlell && !ZS_memcmp(lastline, zleline, zlell)) {
+	lastcs = zlecs;
 	return;
+    }
     for(pre = 0; pre < sh && zleline[pre] == lastline[pre]; )
 	pre++;
     for(suf = 0; suf < sh - pre &&

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Absolute pathnames similar to expand-cmd-path

[Bart Schaefer]

On Jan 29, 11:18pm, Peter Stephenson wrote:
}
} CVS is still down.  It sounds like it's probably time to move to git
} after the next stable release

CVS isn't all that's down, as I understand it.  Based on what they've
blogged, they're concerned that the actual source files may have been
corrupted by the attackers.  I don't think the version control system
being used to access them has any direct connection.

Re: Absolute pathnames similar to expand-cmd-path

[Frank Terbeck]

Peter Stephenson wrote:
[...]
> CVS is still down.  It sounds like it's probably time to move to git
> after the next stable release, nobody's suggested replacing it with an
> even more trendy system yet...

>From <http://sourceforge.net/blog/sourceforge-attack-full-report/>:

  "We are also considering the end-of-life of the CVS service [...]"


I realise, that's not set in stone yet. But we could move at a point of
our choice before we may be forced to do it some time in the future.

I believe, moving to git would make sense, since we already got a synced
mirror of the CVS repository (thanks to Wayne). Git being a distributed
VCS would obviously eliminate the single-point-of-failure weakness of
systems such as CVS or SVN. Another benefit of using git would be, that
you could verify that the history of a remote repository is exactly the
same as the one on your local machine by just comparing the hash-sum of
a commit in question.

Also, if a "central" git repository went down, we could just set up
another "central" one somewhere else from a local one, since the central
and the local one are virtually the same.


To cut a long story short: If we'd be forced to move away from CVS, I
think git makes a lot more sense than SVN (which wouldn't solve the
problem we're having right now).

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: CVS

[Peter Stephenson]

On Sat, 29 Jan 2011 21:48:39 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Jan 29, 11:18pm, Peter Stephenson wrote:
> }
> } CVS is still down.  It sounds like it's probably time to move to git
> } after the next stable release
> 
> CVS isn't all that's down, as I understand it.  Based on what they've
> blogged, they're concerned that the actual source files may have been
> corrupted by the attackers.  I don't think the version control system
> being used to access them has any direct connection.

Yes, there's a lot of stuff down, but for reasons Frank hinted at I
think CVS goes down a lot more than the other systems --- that's why git
is still running.  So there's an indirect link.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

CVS

[Sven Wischnowsky]

Now it has happened for the first time that I got

  cvs [server aborted]: received broken pipe signal

*before* it had updated all modified files I committed. I got this
already several time *after* all files were changed.

Am I the only one seeing this? Is this a problem on our side here or a 
Sourceforge problem?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: CVS

[Adam Spiers]

Oliver Kiddle (opk@u.genie.co.uk) wrote:
> Seeing as all this CVS stuff seems to be approaching being
> semi-official. Could someone who understands it all please write a
> mini-readme to stick in the zsh distribution (or addition to the FAQ)
> which lists all the various cvs mirrors and how someone like me who has
> never used cvs can extract a copy of the latest version of zsh from it.

Seen as I was the person who annoyed everyone by pushing hardest for general
CVS usage, I've written a mini-howto which is below ... Sven, hope this is
useful for you too.  If someone more appropriate than me would like to grab
it and add it to the FAQ/distribution/website/whatever then feel free.  I
agree that we should keep a list of the cvs mirrors somewhere too.

On a vaguely related note, it would be nice to publicise all these new
resources somewhere properly.  zsh-announce and the website should certainly
mention them.  In fact, http://sunsite.auc.dk/zsh/ seems quite out of date in
some respects.  Can anyone do anything about this?  Also, the freshmeat entry
gives ftp://ftp.redhat.com/pub/contrib/i386/ as the location for RPM
packages, but the latest available RPM seems to be 3.1.5.  It would be nice
to have official 3.0.6 RPMs on the zsh ftp site, and have the website link to
these and maybe also the nightly build ones I've just set up (info on
zsh-announce, when the post gets approved), so that RPM fans can easily get
the most recent stable and development versions.  Who's in control of the
website these days?

Anyway, back to the original topic ...

-------- 8< -------- 8< --------
Here's pretty much all you need to know to be able to use the zsh CVS
tree.  It's simplified somewhat because you won't be needing to commit
any changes back into the repository.

First, ensure you have the cvs client installed :-)

To checkout a working copy of the source from the repository:

  cd $WHERE_YOU_WANT_FILES
  cvs -z3 -d :pserver:anonymous@crane.jaist.ac.jp:/projects/zsh login
  cvs -z3 -d :pserver:anonymous@crane.jaist.ac.jp:/projects/zsh checkout zsh

This will put the files in $WHERE_YOU_WANT_FILES/zsh.  You only need
to do the login once (it puts an entry in ~/.cvspass), and you only
need to do the checkout more than once if you messed up your working
copy and decided to rm -rf and start again.

To merge the latest changes to the working copy into your working copy:

  cd $WHERE_YOU_WANT_FILES/zsh
  cvs -z3 update -dP

(Notice that cvs caches the repository location in the CVS/Root file
contained in every subdirectory of the working copy.)

The `-z3' means compress the network traffic (it's a global option,
and so appears before the `update' command).  The `-d' means checkout
any new directories which may have appeared in the repository, and the
`-P' means prune empty directories.  (They are both options specific
to `update'.)

If the update process find changes in the repository to a file you've
modified locally, it will do its best to merge in the changes without
complaining.  However, if you've modified one of the bits in the file
which has been changed in the repository, cvs will warn you of the
conflict and expect you to resolve it by editing the file manually (in
which case, search for `<<<<<' in the file to find the conflict).

To find out differences between your working copy and the repository:

  cd $WHERE_YOU_WANT_FILES/zsh
  cvs diff -u > my.patch

Then the file my.patch should contain a patch in the correct format
for submitting to zsh-workers.  (The `-u' is for unified diffs.)

To create a patch from pure 3.1.6 to say, 3.1.6-bart-8:

  cvs patch -u -rzsh-3_1_6 -rzsh-3_1_6-bart-8 zsh > foo.patch

emacs users have a nice interface to cvs from within emacs.  See the
`Version Control' section of the emacs info pages, or type C-x v C-h
for a quick listing of related key bindings.

cvs is extremely powerful, and there are many more things you can do.
For quick summarised help, type:

  cvs --help
  cvs --help-commands
  cvs --help-options

or

  cvs -H <cvs-command>

where <cvs-command> is something like `update' or `checkout'.  Or read
the cvs man page, or even better, read the info pages, which I would
strongly recommend that you do at some stage.  Even reading through
the overview at the beginning to give you a taster of the concepts
involved would be worthwhile.

Finally, if you find you always use certain switches with certain
commands, you can put them in ~/.cvsrc like this:

  diff -u
  rdiff -u
  update -d

I think that's the lot.  Let me know if you have problems with any of
this.

Adam

CVS

[Oliver Kiddle]

Seeing as all this CVS stuff seems to be approaching being
semi-official. Could someone who understands it all please write a
mini-readme to stick in the zsh distribution (or addition to the FAQ)
which lists all the various cvs mirrors and how someone like me who has
never used cvs can extract a copy of the latest version of zsh from it.

Thanks (and sorry for being too lazy to read the cvs manual)

Oliver

CVS

[Peter Stephenson]

"Bart Schaefer" wrote:
> It is true that adding and removing directories is not the cleanest part
> of CVS, so it would be good to establish some file-structure guidelines
> before we deploy an "official" CVS server.  Just how great the fun will
> be depends on the write-access policy we choose; what were your thoughts?

We shouldn't any more need to add directories unless they going to
hold distinct sets of completions for a particular command set.  I
don't believe it's worth deciding for an individual completion file
whether the command or suite of commands it supports is present or not
--- we could provide an extra script for pruning the installed
functions, if anyone wants to write one --- and hence I don't think
directories like Gnu etc. are particularly useful.  In fact, I can't
currently think of a good example of an extra subdirectory that's
necessary; if the Debian and Linux directories stay fairly empty, I
may put the commands back in User.

To summarise,
- choosing the set of completions appropriate to a local environment
  is more to do with individual mix-and-match on commands than an
  operation en bloc;
- where blocks of commands are concerned, we are now in any case more
  able to provide support in a single file, making new directories
  irrelevant;
- consequently, having extra directories for external commands doesn't
  do the only thing it usefully could do, i.e. help the user with
  organisation.

One thing that might help users through the minefield is a way of
showing what completion will actually be executed in a given context.
To begin with, just being able to find that out for a given command
would be useful.

As far as organizing a CVS archive goes, we could arrange it so that,
for example, Sven made changes to the completion code, and I did it
for the rest, or Bart did in the case of my absence or total
incapacity due to huge volume of patches.  Changes wouldn't appear in
the archive until after they'd been seen on the list --- though at the
present rate of change, how much after is difficult to judge.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56100 Pisa, Italy