Julian Gilbey <[EMAIL PROTECTED]> writes:
> The problem with /usr/local/etc as it stands is that it is in a
> shareable tree. It would be better to have /etc/local and
> /etc/local/share, IMHO.
Theres also another thing that came to my mind. There might be
conffiles that are shareable, but that
On Fri, Jun 18, 1999 at 01:06:18PM -0700, Daniel Quinlan wrote:
> > No... The package puts a file that needs to be modified by the site (and
> > possibly by the individual machine) in /usr/share.. Perhaps the program
> > is at fault for doing this. I do know that lintian will generate an
> > err
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> /etc is intended to be the only repository for configuration
> information. It is machine specific. However, machine-specific does
> not mean that the configuration information in /etc cannot be shared
> between machines. This can be done via symb
Joseph Carter <[EMAIL PROTECTED]> writes:
> No... The package puts a file that needs to be modified by the site (and
> possibly by the individual machine) in /usr/share.. Perhaps the program
> is at fault for doing this. I do know that lintian will generate an
> error on the package should I ru
On Fri, Jun 18, 1999 at 02:17:30AM -0700, Daniel Quinlan wrote:
> > Interesting points. However I would suggest that most of the files in
> > /etc are about local configurations, and are, in general, not
> > shareable. In fact, the FHS defines /etc as being for non-shareable,
>
> You need to be
In article <[EMAIL PROTECTED]> you write:
>Julian Gilbey <[EMAIL PROTECTED]> writes:
>
>> Interesting points. However I would suggest that most of the files in
>> /etc are about local configurations, and are, in general, not
>> shareable. In fact, the FHS defines /etc as being for non-shareable,
Julian Gilbey <[EMAIL PROTECTED]> writes:
> Interesting points. However I would suggest that most of the files in
> /etc are about local configurations, and are, in general, not
> shareable. In fact, the FHS defines /etc as being for non-shareable,
You need to be careful about using the word "s
> On Fri, Jun 18, 1999 at 12:33:21AM +0100, Julian Gilbey wrote:
> > Interesting points. However I would suggest that most of the files in
> > /etc are about local configurations, and are, in general, not
> > shareable. In fact, the FHS defines /etc as being for non-shareable,
> > static data. B
On Fri, 18 Jun 1999, Julian Gilbey wrote:
> Interesting points. However I would suggest that most of the files in
> /etc are about local configurations, and are, in general, not
> shareable. In fact, the FHS defines /etc as being for non-shareable,
> static data. But what should be done for sha
On Fri, Jun 18, 1999 at 12:33:21AM +0100, Julian Gilbey wrote:
> Interesting points. However I would suggest that most of the files in
> /etc are about local configurations, and are, in general, not
> shareable. In fact, the FHS defines /etc as being for non-shareable,
> static data. But what sh
Interesting points. However I would suggest that most of the files in
/etc are about local configurations, and are, in general, not
shareable. In fact, the FHS defines /etc as being for non-shareable,
static data. But what should be done for shareable configuration
data? Debian uses /etc as the
I'd agree with something along these lines, just from my own experiences
with my network, and more recently having to reload both of my surviving
machines pretty much from scratch. (Good reason for having multiple
drives)
My own thought would be to keep the regular config files in /etc or
/etc/,
Julian Gilbey <[EMAIL PROTECTED]> writes:
...
> > --- 7,10
> >
> > umask 002
> > test -x /usr/bin/check-sendfile && /usr/bin/check-sendfile || /bin/true
> > + test -f /usr/local/etc/profile && . /usr/local/etc/profile
>
> Eeks, no! There's no such directory as /usr/local/etc. /
[EMAIL PROTECTED] (Joseph Carter) wrote:
>Not even. pico CANNOT be packaged for Debian! The best that can be done
>is offer the source and let you build it yourself. If you do that, pico
>will provide the editor alternative. If you want it to be the default
>system editor, anybody else using yo
> One of the things that really annoys me about prepackaged
> distributions is the way they tend to ignore everything that isn't in
> packages. E.g., the only way to get non-deb GTK themes in
> /usr/local/share/themes recognized by the GTK config is to link them
> into /usr/share/themes, which is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Waters <[EMAIL PROTECTED]> writes:
> Kyle Rose <[EMAIL PROTECTED]> writes:
>
> > *** profile.origWed Jun 16 12:03:43 1999
> > - --- profile Wed Jun 16 12:04:01 1999
> > ***
> > *** 7,9
> > - --- 7,10
> >
Kyle Rose <[EMAIL PROTECTED]> writes:
> *** profile.origWed Jun 16 12:03:43 1999
> - --- profile Wed Jun 16 12:04:01 1999
> ***
> *** 7,9
> - --- 7,10
>
> umask 002
> test -x /usr/bin/check-sendfile && /usr/bin/check-sendfile || /bin/true
> + test -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Greenland <[EMAIL PROTECTED]> writes:
> On 16-Jun-99, 07:08 (CDT), Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> > Steve Greenland <[EMAIL PROTECTED]> writes:
> > > What's so hard about that? If
> > > you want pico to be the system wide de
On 16-Jun-99, 07:08 (CDT), Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> Steve Greenland <[EMAIL PROTECTED]> writes:
> > What's so hard about that? If
> > you want pico to be the system wide default (god forbid), set EDITOR in
> > /etc/profile and /etc/cshrc (or whatever it's called).
>
> NO,
Steve Greenland <[EMAIL PROTECTED]> writes:
> On 14-Jun-99, 02:06 (CDT), Brock Rozen <[EMAIL PROTECTED]> wrote:
> > On Sun, 13 Jun 1999 at 12:22, Joseph Carter wrote about "Re: Editor and...":
> > > #!/bin/bash
> > > shopt -s execfail
> > > exec ${VISUAL:-${EDITOR:-editor}} "$@"
> >
> > Yes, I sa
On Tue, 15 Jun 1999 at 02:29, Chris Lawrence wrote about "Re: Editor and...":
> That and the "local modification" business is a bit goofy; perhaps
> they should consider a "you modify it, you change the name" policy
> (i.e. you can't call a modified Pine "UW Pine" or "UW PC/Pine"). That
> would a
On Tue, Jun 15, 1999 at 10:05:44AM +0300, Brock Rozen wrote:
> > pico is non-free, so I see no reason to hinge a decision on whether
> > something
> > in debian supports something thats non-free.
>
> To clear up any confusion, the Pine (as such, pico; I believe) license has
> changed and that mig
On Jun 15, Brock Rozen wrote:
> To clear up any confusion, the Pine (as such, pico; I believe) license has
> changed and that might make it eligible to be taken out of "non-free".
A number of problems have been discussed on -legal relative to it;
most notably, that you can put it on a CD-ROM but n
On Mon, 14 Jun 1999 at 18:36, Jim Lynch wrote about "Re: Editor and...":
> Brock Rozen wrote:
> > I didn't see support for pico in this -- thus, I'm against this proposal
> > until sensible-editor has pico support. (If I'm mistaken,and it does have
> > pico support, then I will second this proposa
On 14 Jun 1999 at 12:24, Manoj Srivastava wrote about "Re: Editor and...":
> Yes, the guidelines adopted for policy changes do state that
> only proposals and seconds that count have to be developers. Non
> developers are welcome, and the input provided is listened to, but
> since polic
Hi Brock :)
put this in your .bashrc and/or .bash_profile:
export EDITOR=pico
and see what happens.
Meanwhile, here's something for you to ignore if the above works:
First, the bad news :) If you're not a developer, you don't have a vote, and
you shouldn't be putting your posts in official ter
Brock Rozen wrote:
> I didn't see support for pico in this -- thus, I'm against this proposal
> until sensible-editor has pico support. (If I'm mistaken,and it does have
> pico support, then I will second this proposal).
pico is non-free, so I see no reason to hinge a decision on whether something
Brock Rozen <[EMAIL PROTECTED]> writes:
> I will vote AGAINST this proposal. It's certainly my right [...]
No, if you're not a member of the project, your input is welcome, if
it's sensible, but you don't get a vote, so it's *not* "certainly"
your right.
In this case, your input is not sensible
On Mon, Jun 14, 1999 at 12:40:19PM -0700, Karl M. Hegbloom wrote:
>
> IMHO, any serious Linux user learns to use the emacs, falling back on
> vi. Pico is silly.
Yah and some of us want an editor, not an operating system. We tend to
use vim, joe, jed, or similar... =>
--
Joseph Carter <[EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> IMHO, any serious Linux user learns to use the emacs, falling back on
> vi. Pico is silly.
IMHO, you are silly. One of the appeals of using a UNIX clone over
alternate operating systems is being able to do things the way _you_
want to, not the way
IMHO, any serious Linux user learns to use the emacs, falling back on
vi. Pico is silly.
On 14-Jun-99, 01:51 (CDT), Brock Rozen <[EMAIL PROTECTED]> wrote:
> One works under Debian, the other doesn't. While pico isn't part of
> Debian, there is a package available and I still use it. While that is of
> no interest to you, it makes a whole lot of a difference to me -- and
> since sensib
On 14-Jun-99, 02:06 (CDT), Brock Rozen <[EMAIL PROTECTED]> wrote:
> On Sun, 13 Jun 1999 at 12:22, Joseph Carter wrote about "Re: Editor and...":
> > #!/bin/bash
> > shopt -s execfail
> > exec ${VISUAL:-${EDITOR:-editor}} "$@"
>
> Yes, I saw this. But I didn't see, like the following two lines,
> s
Hi,
>>"Brock" == Brock Rozen <[EMAIL PROTECTED]> writes:
Brock> And while, you may be right (I'm not saying you are) that
Brock> developers should be the only ones seconding and objecting --
Yes, the guidelines adopted for policy changes do state that
only proposals and seconds that co
Brock Rozen <[EMAIL PROTECTED]> writes:
> On 13 Jun 1999 at 14:19, Chris Waters wrote about "Re: Editor and...":
>
> One works under Debian, the other doesn't. While pico isn't part of
> Debian, there is a package available and I still use it. While that is of
> no interest to you, it makes a who
On Mon, Jun 14, 1999 at 10:06:10AM +0300, Brock Rozen wrote:
> > Barring the argument that sensible-editor assumes sensible-user who would
> > never use such a braindead and bloated piece of software for any
> > practical purpose, your argument demonstrates that you need to be fwopped
>
> Fine. Bu
On Sun, 13 Jun 1999 at 12:22, Joseph Carter wrote about "Re: Editor and...":
> I'm about to be harsh on you, so I shall apologize in advance.
As long as we're not commenting on each other's anatomy parts, I think I
can deal with it. ;-)
> Barring the argument that sensible-editor assumes sensibl
On 13 Jun 1999 at 14:19, Chris Waters wrote about "Re: Editor and...":
> > > Editor and sensible-editor
> > > * Under discussion.
> > > * Proposed on 2 Jun 1999 by Goswin Brederlow.
> > > * Instead of having programs use $EDITOR and fall back
Brock Rozen <[EMAIL PROTECTED]> writes:
> On Fri, 11 Jun 1999 at 14:57, Joey Hess wrote about "weekly policy summary":
> > Editor and sensible-editor
> > * Under discussion.
> > * Proposed on 2 Jun 1999 by Goswin Brederlow.
> > * Instead of h
On Sun, Jun 13, 1999 at 08:34:31PM +0300, Brock Rozen wrote:
> On Fri, 11 Jun 1999 at 14:57, Joey Hess wrote about "weekly policy summary":
>
> > Editor and sensible-editor
> > * Under discussion.
> > * Proposed on 2 Jun 1999 by Goswin Brederlow.
> >
Brock Rozen wrote:
> I didn't see support for pico in this -- thus, I'm against this proposal
> until sensible-editor has pico support. (If I'm mistaken,and it does have
> pico support, then I will second this proposal).
Um, unless I'm mistaken it's a matter of pico having sensible-editor
support,
On Fri, 11 Jun 1999 at 14:57, Joey Hess wrote about "weekly policy summary":
> Editor and sensible-editor
> * Under discussion.
> * Proposed on 2 Jun 1999 by Goswin Brederlow.
> * Instead of having programs use $EDITOR and fall back to editor,
> just use sensi
Steve Greenland <[EMAIL PROTECTED]> writes:
> On 03-Jun-99, 09:26 (CDT), Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> > Maybe we could rename sensible-editor to editor. I just hate having
> > two things make the same.
> >
> > editor could be removed and sensible-editor would be renamed to edito
Previously Charles C. Fu wrote:
> You're quite right, of course. I had overlooked ex-mode since I don't
> use it. (Hmm, it might be nice if vim entered ex-mode automatically
> on dumb terminals.)
vim defaults to a builtin ANSI terminal these days, which is probably
a more reasonable choice consi
Previously, I wrote:
>> If you agree with my traditional usage summary, vim would not be
>> suitable because it does not implement open mode and is thus pretty
>> unusable on dumb terminals.
Wichert Akkerman <[EMAIL PROTECTED]> replies:
> Yes it would: if you invoke vim as ex, ... hit Q while in v
Previously Charles C. Fu wrote:
> If you agree with my traditional usage summary, vim would not be
> suitable because it does not implement open mode and is thus pretty
> unusable on dumb terminals.
Yes it would: if you invoke vim as ex, supply the -e option or hit Q
while in vim it will switch to
[EMAIL PROTECTED] (Charles C. Fu) writes:
> Personally, I would prefer to change the policy since it makes EDITOR
> preferred over VISUAL, which is the reverse of the behavior on my
> other systems.
Some historical perspective might be useful here.
The use of EDITOR is an ancient *NIX tradition
On debian-policy, Chris Waters <[EMAIL PROTECTED]> wrote:
>> The EDITOR and VISUAL variables are *NIX traditions, and are
>> already supported by most well-written programs, and even many
>> badly written ones.
Edward Betts <[EMAIL PROTECTED]> writes:
> Talking about the enviroment variables EDITO
On debian-policy, Chris Waters <[EMAIL PROTECTED]> wrote:
> Making this policy would require modifying a *huge* number of
> programs. The EDITOR and VISUAL variables are *NIX traditions, and
> are already supported by most well-written programs, and even many
> badly written ones.
>
> IOW, we sup
J.H.M. Dassen wrote:
> One reason that I can think of is that with $EDITOR, a program can look at
> what editor the user wants, and choose command line options on the basis of
> that; that doesn't work with sensible-editor.
Look at sensible-editor:
#!/bin/bash
shopt -s execfail
exec ${VISUAL:-${E
Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:
> I think we should extend policy by adding a XEDITOR variable that when
> defined overrides de EDITOR var iff we are in X.
Making this policy would require modifying a *huge* number of
programs. The EDITOR and VISUAL variables are *NIX traditions,
> sensible-editor will behave as needed by the current policy, but is
> more flexible. It could start xemacs on X and zile on console or do
> other additional checks. I think policy should state that programs
> should use sensible-editor as their editor.
I think we should extend policy by adding
On 03-Jun-99, 09:26 (CDT), Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> Maybe we could rename sensible-editor to editor. I just hate having
> two things make the same.
>
> editor could be removed and sensible-editor would be renamed to editor
> and call /etc/alternatives/editor when $EDITOR is
Steve Greenland <[EMAIL PROTECTED]> writes:
> On 02-Jun-99, 06:22 (CDT), Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> Goswin, you're absolutely correct. The only issue is that for programs
> which already have 'if (ed=getenv("EDITOR")) system(ed); else
> system("editor")' or somesuch will need
On 02-Jun-99, 06:22 (CDT), Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> Policy states that programms should use $EDITOR if set and else use
> editor as the prefered editor, but why not just use sensible-editor?
>
> sensible-editor will behave as needed by the current policy, but is
> more flexib
On 02-Jun-99, 06:22 (CDT), Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> Policy states that programms should use $EDITOR if set and else use
> editor as the prefered editor, but why not just use sensible-editor?
>
> sensible-editor will behave as needed by the current policy, but is
> more flexib
On Wed, Jun 02, 1999 at 13:22:16 +0200, Goswin Brederlow wrote:
> Policy states that programms should use $EDITOR if set and else use editor
> as the prefered editor, but why not just use sensible-editor?
One reason that I can think of is that with $EDITOR, a program can look at
what editor the us
Policy states that programms should use $EDITOR if set and else use
editor as the prefered editor, but why not just use sensible-editor?
sensible-editor will behave as needed by the current policy, but is
more flexible. It could start xemacs on X and zile on console or do
other additional checks.
58 matches
Mail list logo
