ping Slack dev team
Mike Jones
Reqest to Slackware installation media developers:
Can we (extra pretty) PLEASE have Nano on the install disks?
Midnight Commander would be nice too, and there is plenty of room on the
DVD for these distinctly useful tools.
Ta.
--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.
Lew Pitcher
(N...@Arizona.Bay) wrote:
>
>
> Reqest to Slackware installation media developers:
That would be volk...@slackware.com
> Can we (extra pretty) PLEASE have Nano on the install disks?
>
> Midnight Commander would be nice too, and there is plenty of room on the
> DVD for these distinctly useful tools.
Good idea. I would have thought that those tools would be there, in
the "live system" DVD at least.
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------
Mike Jones
> On November 25, 2009 06:11, in alt.os.linux.slackware, Mike Jones
> (N...@Arizona.Bay) wrote:
>
>
>>
>> Reqest to Slackware installation media developers:
>
> That would be volk...@slackware.com
If one wanted to clog up Pat's email with such trivialities. Simple
posting to this NG should act as a low priority message-in-a-bottle.
>> Can we (extra pretty) PLEASE have Nano on the install disks?
>>
>> Midnight Commander would be nice too, and there is plenty of room on
>> the DVD for these distinctly useful tools.
>
> Good idea. I would have thought that those tools would be there, in the
> "live system" DVD at least.
I get the impression that vi is very popular with developer types, but
unfortunately this doesn't propogate back into userworld that well.
For the record, vi isn't so much an editor as an ingenious puzzle game.
Not the kind of thing you want to find is your only option when
attempting a repair hack from the install bootdisk.
And lets not mention Emacs, eh? 8(
Lew Pitcher
(N...@Arizona.Bay) wrote:
> Responding to Lew Pitcher:
>
>> On November 25, 2009 06:11, in alt.os.linux.slackware, Mike Jones
>> (N...@Arizona.Bay) wrote:
>>
>>
>>>
>>> Reqest to Slackware installation media developers:
>>
>> That would be volk...@slackware.com
>
>
> If one wanted to clog up Pat's email with such trivialities. Simple
> posting to this NG should act as a low priority message-in-a-bottle.
Should. But maybe won't.
PV has said that he no longer follows public slackware groups; something to
do with flamewars and such back in the early releases of Slackware. I know
that a number of his contributors watch (and sometimes participate in)
aols, but there is often no guarantee.
Pat has responded positively to the few suggestions that I have made to him
via email, and I know that he has accepted email suggestions from others in
the group. I believe that he publishes his email address in the
Slackware "welcome" emails specifically so that he can receive direct
feedback.
>>> Can we (extra pretty) PLEASE have Nano on the install disks?
>>>
>>> Midnight Commander would be nice too, and there is plenty of room on
>>> the DVD for these distinctly useful tools.
>>
>> Good idea. I would have thought that those tools would be there, in the
>> "live system" DVD at least.
>
>
> I get the impression that vi is very popular with developer types, but
> unfortunately this doesn't propogate back into userworld that well.
Yes, Vi is one of those Unixisms that Slackware maintains. I agree that most
casual users find Vi too cryptic and complex, and would be better served
(for console mode plain text editing, at least) by Nano or Pico.
> For the record, vi isn't so much an editor as an ingenious puzzle game.
> Not the kind of thing you want to find is your only option when
> attempting a repair hack from the install bootdisk.
>
> And lets not mention Emacs, eh? 8(
No. Let's not. Emacs isn't so much an editor as it is an Operating System
that includes an embedded editor. But, we won't mention that here ;-)
bolta...@yahoo.co.uk
Mike Jones <N...@Arizona.Bay> wrote:
>For the record, vi isn't so much an editor as an ingenious puzzle game.
>Not the kind of thing you want to find is your only option when
>attempting a repair hack from the install bootdisk.
Anyone who can repair a system from the bootdisk system is probably more
than capable of using vi. Yes its rubbish but vi is the de facto standard unix
text editor and you must assume that one day it might be your only option and
hence you should learn it.
B2003
Lew Pitcher
> Pat has responded positively to the few suggestions that I have
> made to him via email, and I know that he has accepted email
> suggestions from others in the group.
Um, the fact that his system automatically responds to your sorry
attempts to be noticed, does not constitute a "positive" response.
> I believe that ....
Nobody cares what you believe. Trust me. They don't care.
> Yes, Vi is one of those Unixisms that Slackware maintains. I agree
> that most casual users find Vi too cryptic and complex, and would
> be better served (for console mode plain text editing, at least)
> by Nano or Pico.
Nobody cares what you believe. And the Nano or Pico editors are,
essentially, worthless. The best editors not named vi* are joe and
mc.
> No. Let's not. Emacs isn't so much an editor as it is an Operating
> System that includes an embedded editor. But, we won't mention
> that here ;-)
No, emacs is not an operating system. And the attempts at hyperbole
are hackneyed and dated and not funny.
More accurately, Emacs is an antique Edsel or perhaps a DeLorean,
and while there will always be hobbyists who like to tinker with
this kind of crap, such people will never be taken seriously by
mainstream computer folk.
But then being taken seriously would be a totally unique experience
for you, wouldn't it, eh, "Lew?"
LewPitcher.ca is registered to _me!_ Moi! Not you!
First you steal justlinux.ca and now you try to claim LewPitcher.ca.
Why don't you try to use what little imagination you have and come
up with another name? Impress us all, "Lew", and create your own
name, ok?
I don't think PV has maintained his trademark registration for
"Slackware." Why don't you pounce on that? +TheCowardHicks+ would
only be too glad to help you.
LewPi...@LewPitcher.ca
--
Official Website -->> http://lewpitcher.ca/
Something to look at: -->> http://www.emusclemag.com/
Lonely in Brampton? -->> http://gaypros.meetup.com/cities/ca/on/brampton/
Peel HIV/AIDS Network -->> http://www.phan.ca/home.html
Lew Pitcher
> Anyone who can repair a system from the bootdisk system is
> probably more than capable of using vi. Yes its rubbish but vi is
> the de facto standard unix text editor and you must assume that
> one day it might be your only option and hence you should learn
> it.
If you want to think in a minimal, survivalist manner, you should
lookup the "ex" command.
Keith Keller
>
> If one wanted to clog up Pat's email with such trivialities. Simple
> posting to this NG should act as a low priority message-in-a-bottle.
Why should it? It's some random usenet newsgroup, which he may or may
not monitor (as Lew says, Pat has stated he does not). His email is the
''official'' way to request changes. (Presumably he has another address
that he uses for personal correspondence, so you shouldn't consider
legitimate requests, even if low priority, clogging up his box.)
You might ask if SlackBuilds will support a build script (or better
still, you can provide one).
> I get the impression that vi is very popular with developer types, but
> unfortunately this doesn't propogate back into userworld that well.
Developers (and sysadmins!) are users too! *sob*
--keith
--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
Mike Jones
[...]
>> And lets not mention Emacs, eh? 8(
>
> No. Let's not. Emacs isn't so much an editor as it is an Operating
> System that includes an embedded editor. But, we won't mention that
> here ;-)
Its got an editor in there? Wow! %|
Mike Jones
> On 2009-11-25, Mike Jones <N...@Arizona.Bay> wrote:
>>
>> If one wanted to clog up Pat's email with such trivialities. Simple
>> posting to this NG should act as a low priority message-in-a-bottle.
>
> Why should it? It's some random usenet newsgroup, which he may or may
> not monitor (as Lew says, Pat has stated he does not). His email is the
> ''official'' way to request changes. (Presumably he has another address
> that he uses for personal correspondence, so you shouldn't consider
> legitimate requests, even if low priority, clogging up his box.)
>
> You might ask if SlackBuilds will support a build script (or better
> still, you can provide one).
>
>> I get the impression that vi is very popular with developer types, but
>> unfortunately this doesn't propogate back into userworld that well.
>
> Developers (and sysadmins!) are users too! *sob*
>
> --keith
Kinda made my point really. ;)
Mike Jones
I can also slam my hand in a car door repeatedly, but there are better
ways to close a car door too. :\
I found much better tools than the overly-incantational vi (and clones),
and Nano is streets ahead as a lightweight intuitive "pick it up and use
it" terminal tool. This is why I consider it to be the best fallback
editor over some other stuff that just soaks up too much brainspace when
you're trying to figure out what went wrong with something else.
If you're going to have obscure stuff like joe and jove in the default
install, the Nano should be in there too, to be fair about it.
Henrik Carlqvist
> Reqest to Slackware installation media developers:
>
> Can we (extra pretty) PLEASE have Nano on the install disks?
In case you wont get your request fulfilled and still feel the need for
these or other applications it might be useful to know that it is rather
easy to customize the installation disk.
I have written a Makefile to build my own installation disks with custom
contents:
-8<---------------------------------------------
PACKAGE_DIRS = $(shell find ../slackware/ \( -type d -o -type l \) \
-exec basename {} \;| \
grep -v slackware | grep -v PACKAGES.TXT )
KERNELS = $(shell find kernels/ \( -type d -o -type l \) \
-exec basename {} \;| \
grep -v kernels | sort | xargs echo )
BZIMAGES = $(KERNELS:%=kernels/%/bzImage)
KERNEL_VERSION = 2.6.24.5
LINUX_SRC = kernel_and_patches/linux-$(KERNEL_VERSION).tar.gz
PATCHES = $(wildcard kernel_and_patches/*.patch)
PKG_BUILD_DIR = /var/tmp/henca/tmp/pkg_build
KERNEL_BUILD_DIR = /var/tmp/kernel_build/linux-$(KERNEL_VERSION)
.INTERMEDIATE: $(KERNEL_BUILD_DIR) $(PKG_BUILD_DIR)
KERNEL_PATCH_PKG_DIR = slackware/kernel-upgrades
PREV_PATCH_NR = $(shell ((ls $(KERNEL_PATCH_PKG_DIR)/*.tgz 2> /dev/null || \
echo 1) | \
sed -e 's/.tgz//' | \
awk 'BEGIN {FS="-"} ; {print $$NF}' | sort | tail -1))
PATCH_NR = $(strip $(shell (ls $(KERNEL_PATCH_PKG_DIR)/*.tgz 2> /dev/null || \
echo 0) | \
sed -e 's/.tgz//' | \
awk 'BEGIN {FS="-"} ; {print $$NF}' | sort | tail -1 | \
xargs echo 1+ | bc ))
PREV_PATCH_PKG_FILE= kernel-patches-$(KERNEL_VERSION)-i486-$(PREV_PATCH_NR).tgz
KERNEL_PATCH_PKG_FILE = kernel-patches-$(KERNEL_VERSION)-i486-$(PATCH_NR).tgz
PREV_PATCH_PKG = $(KERNEL_PATCH_PKG_DIR)/$(PREV_PATCH_PKG_FILE)
KERNEL_PATCH_PKG= $(shell pwd)/$(KERNEL_PATCH_PKG_DIR)/$(KERNEL_PATCH_PKG_FILE)
# Clean up kernel build directory
all: /var/tmp/dvd_install.iso
$(RM) -r $(KERNEL_BUILD_DIR) $(PKG_BUILD_DIR)
# Only one kernel can be built at a time
.NOTPARALLEL:
/var/tmp/dvd_install.iso: nfs_install.iso isolinux/setpkg.nfs \
$(wildcard slackware/*/*) \
$(PREV_PATCH_PKG)
cd isolinux && ln -sf setpkg.dvd setpkg && cd ..
mkisofs -o $@ \
-R -J -V "My Slamd121 Install `date +%y%m%d`" \
-hide-rr-moved -f\
-v -d -N -no-emul-boot -boot-load-size 4 -boot-info-table \
-sort isolinux/iso.sort \
-b isolinux/isolinux.bin \
-c isolinux/isolinux.boot \
-x initrd_src \
-A "My Slamd121 Install DVD" .
echo $@ created
nfs_install.iso: isolinux/isolinux.cfg \
isolinux/message.txt \
isolinux/initrd.img \
isolinux/setpkg.nfs \
$(wildcard isolinux/*.img isolinux/*.dsk)
cd isolinux && ln -sf setpkg.nfs setpkg && cd ..
mkisofs -o $@ \
-R -J -V "My Slamd121 NFS Install `date +%y%m%d`" \
-hide-rr-moved -f\
-v -d -N -no-emul-boot -boot-load-size 4 -boot-info-table \
-sort isolinux/iso.sort \
-b isolinux/isolinux.bin \
-c isolinux/isolinux.boot \
-x slackware \
-x nfs_install.iso \
-x initrd_src \
-A "My Slamd121 NFS Install CD" .
isolinux/isolinux.cfg: isolinux/isolinux.cfg.start isolinux/message.txt
cp $@.start $@
for KERNEL in $(KERNELS); do \
echo "label $$KERNEL" >> $@; \
echo "kernel /kernels/$$KERNEL/bzImage" >> $@; \
echo -n "append initrd=initrd.img load_ramdisk=1 " >> $@; \
echo "prompt_ramdisk=0 rw SLACK_KERNEL=$$KERNEL" >> $@; \
done
isolinux/message.txt: isolinux/message.txt.start $(BZIMAGES)
cp $@.start $@
echo $(KERNELS) | fold -s >> $@
isolinux/initrd.img: initrd_src $(shell find initrd_src -type d -o -type f )
cd $< && find . | cpio -o -H newc | gzip > ../$@
initrd_src:
ifeq ($(shell whoami),root)
mkdir $@ && cd $@ && gzip -d < ../isolinux/initrd.img | cpio -i
else
@echo Run \"make initrd_src\" as root! && false
endif
slack_dirs:
find slackware -type l -exec $(RM) {} \;
cd slackware && \
ln -s $(foreach DIR, $(PACKAGE_DIRS), ../../slackware/$(DIR)) .
kernels/%/bzImage: $(KERNEL_BUILD_DIR) kernels/%/config
echo Compiling $@
cp $(@D)/config $</.config
cd $< && make bzImage
$(RM) $(@D)/System.map.gz
cp $</arch/x86_64/boot/bzImage $@
cp $</System.map $(@D)
gzip -9 $(@D)/System.map
$(KERNEL_BUILD_DIR): $(LINUX_SRC) $(wildcard kernels/*/config) $(PATCHES)
mkdir -p $(@D)
cat $< | (cd $(@D) && tar -xzvf -)
$(foreach PATCH, $(PATCHES), \
cat $(PATCH) | (cd $@ && patch -p1) &&) true;
$(PREV_PATCH_PKG): $(BZIMAGES)
( echo " Patched kernel" && echo && \
tail -9 kernel_and_patches/patches.txt | \
awk '{$$1=""; print $$0}' && printf "\n\n\n\n\n\n\n\n\n\n" ) | \
sed -e 's/^/kernel-patches:/' | head -11 > \
$(KERNEL_PATCH_PKG:%.tgz=%.txt)
mkdir -p $(PKG_BUILD_DIR)/install/new_kernels
cp -rp $(KERNELS:%=kernels/%) $(PKG_BUILD_DIR)/install/new_kernels
cp kernel_and_patches/doinst.sh $(PKG_BUILD_DIR)/install
cd $(PKG_BUILD_DIR) && /sbin/makepkg -c n $(KERNEL_PATCH_PKG)
-8<---------------------------------------------
The rule to look at above is the rule for isolinux/initrd.img which takes
the contents of initrd_src and creates your new initrd.img. If you have
a working nano in the directory tree of initrd_src you will get nano on
the installation disk.
If initrd_src doesn't already exist it is created by unpacking the
contents of your current isolinux/initrd.img. This unpacking with cpio has
to be done as root to keep ownership of files in the directory tree, all
the other targets can be built as a normal user.
The Makefile above does a lot more than just creating a custom initrd.img,
it also patches and builds kernels with different configurations and
creates a install DVD image as well as a smaller CD image used for NFS
installs. Your imagination is the only limit on how Slackware can be
customized.
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost
Grant
>
>
>Reqest to Slackware installation media developers:
>
>Can we (extra pretty) PLEASE have Nano on the install disks?
Use vi, it's on any unix or unix-like OS -- worth knowing vi for that
reason alone.
>
>Midnight Commander would be nice too, and there is plenty of room on the
>DVD for these distinctly useful tools.
Why? It's a clone of an old messy-dos tool.
Grant.
--
http://bugsplatter.id.au
Dan C
> Responding to boltar2003:
>
>> On Wed, 25 Nov 2009 16:15:27 GMT
>> Mike Jones <N...@Arizona.Bay> wrote:
>>>For the record, vi isn't so much an editor as an ingenious puzzle game.
>>>Not the kind of thing you want to find is your only option when
>>>attempting a repair hack from the install bootdisk.
>>
>> Anyone who can repair a system from the bootdisk system is probably
>> more than capable of using vi. Yes its rubbish but vi is the de facto
>> standard unix text editor and you must assume that one day it might be
>> your only option and hence you should learn it.
>>
>> B2003
>
>
> I can also slam my hand in a car door repeatedly, but there are better
> ways to close a car door too. :\
Poor logic, and poor analogy.
> I found much better tools than the overly-incantational vi (and clones),
> and Nano is streets ahead as a lightweight intuitive "pick it up and use
> it" terminal tool. This is why I consider it to be the best fallback
> editor over some other stuff that just soaks up too much brainspace when
> you're trying to figure out what went wrong with something else.
Did you miss the part about 'vi' being the de facto standard unix text
editor, which will nearly always be available on any *nix system? Not
knowing how to use it does yourself a disservice. What will you do if
someday you are called upon to fix/edit a real Unix system?
It's no harder to use than anything else, once you spend an hour or two
learning it. You probably spent more time on learning your newsreader,
or email client. Why not learn an editor in the same fashion?
--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".
"Bother!" said Pooh, as he wiped the vomit from his chin.
Usenet Improvement Project: http://twovoyagers.com/improve-usenet.org/
Keith Keller
>
> You might ask if SlackBuilds will support a build script (or better
> still, you can provide one).
Ah, I misunderstood the question, sorry. You'd need to build your own
install image, not just a slackbuild. In this case, I think building a
custom image is documented on the Slackware DVD, but I could be wrong
about that.
Grant
>Mike Jones <N...@arizona.bay> wrote:
>
>> If you're going to have obscure stuff like joe and jove in the default
>> install, the Nano should be in there too, to be fair about it.
>
>hey, nothing obscure here, I like joe,
>wordstar and TurboPascal key movement is deeply ingrained in me for
^^^^^^^^--> my left hand still hates wordstar cursor movement ;)
>decades
Grant.
--
http://bugsplatter.id.au
Lew Pitcher
> Mike Jones <N...@arizona.bay> wrote:
>
>> If you're going to have obscure stuff like joe and jove in the default
>> install, the Nano should be in there too, to be fair about it.
>
> wordstar and TurboPascal key movement is deeply ingrained in me for
Don't forget Sidekick! (Wasn't that a great program for its day?)
Lew Pitcher
Much more than that. It's got ftp builtin which is great and the
original NC never had that.
Dan C
> Grant <g_r_a...@bugsplatter.id.au> trolled:
>> On Wed, 25 Nov 2009 11:11:21 GMT, Mike Jones <N...@Arizona.Bay> wrote:
>>
>>
>>>
>>>Reqest to Slackware installation media developers:
>>>
>>>Can we (extra pretty) PLEASE have Nano on the install disks?
>>
>> Use vi, it's on any unix or unix-like OS -- worth knowing vi for that
>> reason alone.
>>>
>>>Midnight Commander would be nice too, and there is plenty of room on
>>>the DVD for these distinctly useful tools.
>>
>> Why? It's a clone of an old messy-dos tool.
>
> Much more than that. It's got ftp builtin which is great and the
> original NC never had that.
MC is a piece of crap. It figures the troll 'rm' would favor it.
Bugger off, troll.
Joe
> On Wed, 25 Nov 2009 20:11:43 +0000, Mike Jones wrote:
>
>> I found much better tools than the overly-incantational vi (and clones),
>> and Nano is streets ahead as a lightweight intuitive "pick it up and use
>> it" terminal tool. This is why I consider it to be the best fallback
>> editor over some other stuff that just soaks up too much brainspace when
>> you're trying to figure out what went wrong with something else.
>
> Did you miss the part about 'vi' being the de facto standard unix text
> editor, which will nearly always be available on any *nix system? Not
> knowing how to use it does yourself a disservice. What will you do if
> someday you are called upon to fix/edit a real Unix system?
Yeah, but then the default Linux editor shouldn't be some "enhanced" stuff like vim.
I once wasted a couple hours because vim "conveniently" hid control characters.
It turned out that the wanna-be sysadmin had edited a redhat /etc/init.d/ file
under DOS and it had cr/lf instead of just lf for line endings.
The real vi on Solaris or any other "real" Unix would have shown me that
immediately.
Give me a plain vi any day, just not this idiotic "enhanced" crap. Plain vi is
the standard, and works everywhere. vim is no better than nano in that it is a
niche tool.
-Joe
Michael Black
>
> Reqest to Slackware installation media developers:
>
> Can we (extra pretty) PLEASE have Nano on the install disks?
>
> Midnight Commander would be nice too, and there is plenty of room on the
> DVD for these distinctly useful tools.
>
Am I missing the question? Both Nano and MC are in Slackware 13 (and
they are in 12.0 too). Nano is a variant of Pico, and Pico has long been
included, I guess always as part of the Pine package. I've not checked,
but Nano may now be the editor included with the Alpine package (Alpine
being a variant of Pine, and the one that's included in Slack 13).
The "install disk" is now the DVD (or multiple CDROMs, so the stuff
is there.
The only other way I can interpret your question is that you think it
should be available when booting the DVD during the install phase.
Michael
Keith Keller
> On Wed, 25 Nov 2009, Mike Jones wrote:
>
>> Reqest to Slackware installation media developers:
>>
>> Can we (extra pretty) PLEASE have Nano on the install disks?
>
> they are in 12.0 too).
> The only other way I can interpret your question is that you think it
> should be available when booting the DVD during the install phase.
Based on the rest of the thread that is what I believe the OP wants.
Helmut Hullen
Du meintest am 25.11.09:
>> Can we (extra pretty) PLEASE have Nano on the install disks?
> Nano is a variant of Pico, and Pico has long
> been included, I guess always as part of the Pine package.
No - it's an own package. At least since 3 years.
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Mikhail Zotov
Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
> Mike Jones <N...@Arizona.Bay> wrote:
> > Reqest to Slackware installation media developers:
> >
> > Can we (extra pretty) PLEASE have Nano on the install disks?
>
> In case you wont get your request fulfilled and still feel the need for
> these or other applications it might be useful to know that it is rather
> easy to customize the installation disk.
>
> I have written a Makefile to build my own installation disks with custom
> contents:
Henrik, is this Makefile available somewhere in the Net? I think, many
people would be interested in trying/using it.
--
Mikhail
Res
>>> Reqest to Slackware installation media developers:
>>
>> That would be volk...@slackware.com
>
>
> If one wanted to clog up Pat's email with such trivialities. Simple
> posting to this NG should act as a low priority message-in-a-bottle.
>
Nope, Pat does not read this NG, its full of wankers so why would he :)
Pat alone has the only say of what goes into Slackware.
He's kind of open to dicscussion, I had talked to him about a few programs
I think should be in it by default (such as postfix, dovecot, and I threw
in pureftpd as well for measure), he suggested those in slackbuilds, I
then suggested that they are very mainstream programs and it would be
beneficial to have them in the offical release, like most every other
distro does (at least with postfix and dovecot), I guess we'll know in
time if he deicdes to, but since that was over a month ago and there's no
appearance in -current I dare say he isn't going to in the near future.
>>> Midnight Commander would be nice too, and there is plenty of room on
huh ? 'mc' is, and has been, in Slackware for a very *long* time.
--
Res
"What does Windows have that Linux doesn't?" - One hell of a lot of bugs!
Clemens Ladisch
> On Wed, 25 Nov 2009, Mike Jones wrote:
> > Can we (extra pretty) PLEASE have Nano on the install disks?
>
> The only other way I can interpret your question is that you think it
> should be available when booting the DVD during the install phase.
The Slackware installer uses busybox, so vi (and ed) is all that's
available then. It runs from a RAM disk, so it's very unlikely that a
separate editor will be added, even one as small as nano.
Best regards,
Clemens
Mike Jones
> On Wed, 25 Nov 2009 11:11:21 GMT, Mike Jones <N...@Arizona.Bay> wrote:
>
>
>>
>>Reqest to Slackware installation media developers:
>>
>>Can we (extra pretty) PLEASE have Nano on the install disks?
>
> Use vi, it's on any unix or unix-like OS -- worth knowing vi for that
> reason alone.
No. Use Nano, and make sure its a regular component. Its been around long
enough to be a standard and does not take up any significant space on a
distro disk. Its *NIX standard in operation, and, most importantly, its
almost a no-brainer to use. No having to learn reams of "WTF?"
incantations while the customer\family\burgler\CIA_agent\etc. stand
around tapping their foot.
Contrary to some occasionally amusing urban myths, Vi is not an editor.
Its a puzzle game /disguised/ as an editor. Entertaining and even useful
to those who have brains capable of performing the hoop-jumping required
to pilot such a beast, but a not-very-funny practical joke to those who
require their "OMG! Where is the text editor?" save-the-day tool to "just
****ing WORK FFS!" Nano fulfills this requirement. Vi contributes to
physically damaged hardware. Emacs, to take this to extremes, is just
sadism in software form, or masochism, if you're into that kind of thing.
So, Nano should be the default editor on EVERYTHING, including kettles.
BTW, banging your head against a wall is not a good idea, no matter how
many people do it, "Because the wall is there". ;\
>>
>>Midnight Commander would be nice too, and there is plenty of room on the
>>DVD for these distinctly useful tools.
>
> Why? It's a clone of an old messy-dos tool.
Its a very useful tool. It weighs next to nothing. Its been around for so
long now its a "standard". There is space on the DVD for it. See the
"Advanced Midnight Commander" stuff for more on how MC protects against
RSI injuries, reduces arthritic pain, and other benefits.
I still use it as my default file manager. Its works nearly anywhere.
Mike Jones
Nano is a no brainer to use. In an emergency, that counts.
Vi is, compared to a lot of "standard" Linux stuff, pointlessly complex
when trying to perform even simple text editing tasks. Its not an editor
in the traditional sense, and while it may indeed be useful to advance
sysadmins debugging their own work on the fly, its a bad joke to the
average end user trying to climb out of a problem in the dark.
IOW, when the sh.1T hits the fan, finding Vi when you need an editor and
fast, is like Bugs Bunny handing you an anvil in a parachute backpack.
WEEEEEeeeee
e
e
e
e
e
e
e
e
\|/
!POF!
Vi's dithpicable!
Eef Hartman
> If you're going to have obscure stuff like joe and jove in the default
> install, the Nano should be in there too, to be fair about it.
But nano (and mc) _are_ in the (13.0 probably "and before") distribution
(the tagfile for the "ap" set gives:
jed:OPT
joe:OPT
jove:OPT
mc:OPT
nano:REC
in which "OPT" means optional, the question in an interactive install
will have as default NO, while REC is recommended, the question has
as default YES).
The other two are ADD (the package will be added without a question)
and SKP (no question, no install skipped).
You can create your own tagfiles with the "maketag" script in each
fileset.
--
*******************************************************************
** Eef Hartman, Delft University of Technology, dept. SSC/ICT **
** e-mail: E.J.M....@tudelft.nl - phone: +31-15-278 82525 **
*******************************************************************
Mike Jones
> On 2009-11-26, Michael Black <et...@ncf.ca> wrote:
>> On Wed, 25 Nov 2009, Mike Jones wrote:
>>
>>> Reqest to Slackware installation media developers:
>>>
>>> Can we (extra pretty) PLEASE have Nano on the install disks?
>>
>> Am I missing the question? Both Nano and MC are in Slackware 13 (and
>> they are in 12.0 too).
> [snip]
>> The only other way I can interpret your question is that you think it
>> should be available when booting the DVD during the install phase.
>
> Based on the rest of the thread that is what I believe the OP wants.
>
> --keith
Yup.
Eef Hartman
> If you want to think in a minimal, survivalist manner, you should
> lookup the "ex" command.
If you really wanna go minimal, look up "ed" (i.e. the stream editor,
sed, is derived from THAT, nor from the EXtended editor ex).
Mike Jones
Something as small as Nano = no, but Vi, which is huge (and complex) by
comparison, is the standard? From the installation disk boot? This
doesn't add up.
Surely the lightest editor (143kB on my system) would make sense. I get
the idea Vi is included in so many places because those who do the
hacking and tweaking, and the developing, all use it. This doesn't mean
its a useful tool to end users and casual dabblers like moi though.
Hmmm...?
http://www.theregister.co.uk/1999/05/27/half_of_users_attack_their/
;\
Martin Schmitz
> Something as small as Nano = no, but Vi, which is huge (and complex)
> by comparison, is the standard? From the installation disk boot? This
> doesn't add up.
Nano is about five times bigger than standard vi (in disksize, in
functionality vi is about 100 times "bigger"):
[dakini]~$ ls -l /usr/bin/nano /usr/bin/nvi
-rwxr-xr-x 1 root root 145884 2008-09-16 02:07 /usr/bin/nano
-rwxr-xr-x 3 root root 30354 2009-04-05 15:39 /usr/bin/nvi
Martin
Eef Hartman
> Something as small as Nano = no, but Vi, which is huge (and complex) by
> comparison, is the standard? From the installation disk boot?
The "vi" in the ramdisk image is NOT a separate program, it is one of
the many commands, served by the single "busybox" executable
(all commands are just sym-links TO that executable):
BusyBox combines tiny versions of many common UNIX utilities into a
single small executable. It provides minimalist replacements for most
of the utilities you usually find in GNU coreutils, util-linux, etc.
The utilities in BusyBox generally have fewer options than their
full-featured GNU cousins; however, the options that are included
provide the expected functionality and behave very much like their
GNU counterparts.
The "vi" in busybox is probably less then 50 KB and has the following
command syntax:
vi
vi [OPTIONS] [FILE]...
Edit FILE
Options:
-c Initial command to run ($EXINIT also available)
-R Read-only - do not write to the file
-H Short help regarding available features
(from the busybox website: http://www.busybox.net).
PS: the ls, rm, cp and e.g. grep and gunzip commands are in busybox
too, Pat _is_ using a separate "tar" executable, but there is a
minimal tar in busybox too).
Lew Pitcher
(E.J.M....@tudelft.nl) wrote:
> Mike Jones <N...@arizona.bay> wrote:
>> If you're going to have obscure stuff like joe and jove in the default
>> install, the Nano should be in there too, to be fair about it.
>
> But nano (and mc) _are_ in the (13.0 probably "and before") distribution
> (the tagfile for the "ap" set gives:
> jed:OPT
> joe:OPT
> jove:OPT
> mc:OPT
> nano:REC
[snip]
I took the OP's request to mean to ask for Nano on the "Live system" part of
the install DVD. Nano and Pico have been readily available as parts of
install packages for quite some time.
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------
Helmut Hullen
Du meintest am 26.11.09:
> But nano (and mc) _are_ in the (13.0 probably "and before")
> distribution (the tagfile for the "ap" set gives:
> jed:OPT
> joe:OPT
> jove:OPT
> mc:OPT
> nano:REC
> in which "OPT" means optional, the question in an interactive install
> will have as default NO, while REC is recommended, the question has
> as default YES).
And "pico" is part of "pine" (and "alpine"), CLI users may install it
too.
Mike Jones
Ah. This is a different situation to just sticking a text editor into a
dir then.
Mike Jones
I can see how that would sway a decision as to which editor to include.
Mike Jones
> Mike Jones <N...@Arizona.Bay> wrote:
>> Reqest to Slackware installation media developers:
>>
>> Can we (extra pretty) PLEASE have Nano on the install disks?
>
> In case you wont get your request fulfilled and still feel the need for
> these or other applications it might be useful to know that it is rather
> easy to customize the installation disk.
>
> I have written a Makefile to build my own installation disks with custom
> contents:
>
> -8<--------------------------------------------- PACKAGE_DIRS = $(shell
> find ../slackware/ \( -type d -o -type l \) \
> -exec basename {} \;| \
> grep -v slackware | grep -v PACKAGES.TXT )
> KERNELS = $(shell find kernels/ \( -type d -o -type l \) \
> -exec basename {} \;| \
> grep -v kernels | sort | xargs echo )
> BZIMAGES = $(KERNELS:%=kernels/%/bzImage)
>
> KERNEL_VERSION = 2.6.24.5
>
> LINUX_SRC = kernel_and_patches/linux-$(KERNEL_VERSION).tar.gz PATCHES =
> $(wildcard kernel_and_patches/*.patch)
>
> PKG_BUILD_DIR = /var/tmp/henca/tmp/pkg_build KERNEL_BUILD_DIR =
> /var/tmp/kernel_build/linux-$(KERNEL_VERSION)
>
> .INTERMEDIATE: $(KERNEL_BUILD_DIR) $(PKG_BUILD_DIR)
>
> KERNEL_PATCH_PKG_DIR = slackware/kernel-upgrades
>
> PREV_PATCH_NR = $(shell ((ls $(KERNEL_PATCH_PKG_DIR)/*.tgz 2> /dev/null
> || \
> echo 1) | \
> sed -e 's/.tgz//' | \
> awk 'BEGIN {FS="-"} ; {print $$NF}' | sort | tail
> -1))
>
> PATCH_NR = $(strip $(shell (ls $(KERNEL_PATCH_PKG_DIR)/*.tgz 2>
> /dev/null || \
> echo 0) | \
> sed -e 's/.tgz//' | \
> awk 'BEGIN {FS="-"} ; {print $$NF}' | sort | tail -1 | \
> xargs echo 1+ | bc ))
> PREV_PATCH_PKG_FILE=
> kernel-patches-$(KERNEL_VERSION)-i486-$(PREV_PATCH_NR).tgz
> KERNEL_PATCH_PKG_FILE =
> kernel-patches-$(KERNEL_VERSION)-i486-$(PATCH_NR).tgz PREV_PATCH_PKG =
> $(KERNEL_PATCH_PKG_DIR)/$(PREV_PATCH_PKG_FILE) KERNEL_PATCH_PKG= $(shell
> pwd)/$(KERNEL_PATCH_PKG_DIR)/$(KERNEL_PATCH_PKG_FILE)
>
> # Clean up kernel build directory
> all: /var/tmp/dvd_install.iso
> $(RM) -r $(KERNEL_BUILD_DIR) $(PKG_BUILD_DIR)
>
> # Only one kernel can be built at a time .NOTPARALLEL:
>
> /var/tmp/dvd_install.iso: nfs_install.iso isolinux/setpkg.nfs \
> $(wildcard slackware/*/*) \
> $(PREV_PATCH_PKG)
> cd isolinux && ln -sf setpkg.dvd setpkg && cd .. mkisofs -o $@ \
> -R -J -V "My Slamd121 Install `date +%y%m%d`" \ -hide-rr-moved
> -f\
> -v -d -N -no-emul-boot -boot-load-size 4 -boot-info-table \
> -sort isolinux/iso.sort \
> -b isolinux/isolinux.bin \
> -c isolinux/isolinux.boot \
> -x initrd_src \
> -A "My Slamd121 Install DVD" .
> echo $@ created
>
> nfs_install.iso: isolinux/isolinux.cfg \
> isolinux/message.txt \
> isolinux/initrd.img \
> isolinux/setpkg.nfs \
> $(wildcard isolinux/*.img isolinux/*.dsk)
> cd isolinux && ln -sf setpkg.nfs setpkg && cd .. mkisofs -o $@ \
> -R -J -V "My Slamd121 NFS Install `date +%y%m%d`" \
> -hide-rr-moved -f\
> -v -d -N -no-emul-boot -boot-load-size 4 -boot-info-table \
> -sort isolinux/iso.sort \
> -b isolinux/isolinux.bin \
> -c isolinux/isolinux.boot \
> -x slackware \
> -x nfs_install.iso \
> -x initrd_src \
> -A "My Slamd121 NFS Install CD" .
>
> isolinux/isolinux.cfg: isolinux/isolinux.cfg.start isolinux/message.txt
> cp $@.start $@
> for KERNEL in $(KERNELS); do \
> echo "label $$KERNEL" >> $@; \
> echo "kernel /kernels/$$KERNEL/bzImage" >> $@; \ echo -n
> "append initrd=initrd.img load_ramdisk=1 " >> $@; \ echo
> "prompt_ramdisk=0 rw SLACK_KERNEL=$$KERNEL" >> $@; \
> done
>
> isolinux/message.txt: isolinux/message.txt.start $(BZIMAGES)
> cp $@.start $@
> echo $(KERNELS) | fold -s >> $@
>
> isolinux/initrd.img: initrd_src $(shell find initrd_src -type d -o -type
> f )
> cd $< && find . | cpio -o -H newc | gzip > ../$@
>
> initrd_src:
> ifeq ($(shell whoami),root)
> mkdir $@ && cd $@ && gzip -d < ../isolinux/initrd.img | cpio -i
> else
> @echo Run \"make initrd_src\" as root! && false
> endif
> slack_dirs:
> find slackware -type l -exec $(RM) {} \; cd slackware && \
> ln -s $(foreach DIR, $(PACKAGE_DIRS), ../../slackware/$(DIR)) .
>
> kernels/%/bzImage: $(KERNEL_BUILD_DIR) kernels/%/config
> echo Compiling $@
> cp $(@D)/config $</.config
> cd $< && make bzImage
> $(RM) $(@D)/System.map.gz
> cp $</arch/x86_64/boot/bzImage $@
> cp $</System.map $(@D)
> gzip -9 $(@D)/System.map
>
> $(KERNEL_BUILD_DIR): $(LINUX_SRC) $(wildcard kernels/*/config)
> $(PATCHES)
> mkdir -p $(@D)
> cat $< | (cd $(@D) && tar -xzvf -)
> $(foreach PATCH, $(PATCHES), \
> cat $(PATCH) | (cd $@ && patch -p1) &&) true;
>
> $(PREV_PATCH_PKG): $(BZIMAGES)
> ( echo " Patched kernel" && echo && \
> tail -9 kernel_and_patches/patches.txt | \ awk '{$$1="";
> print $$0}' && printf "\n\n\n\n\n\n\n\n\n\n" ) | \ sed -e
> 's/^/kernel-patches:/' | head -11 > \
> $(KERNEL_PATCH_PKG:%.tgz=%.txt)
> mkdir -p $(PKG_BUILD_DIR)/install/new_kernels cp -rp
> $(KERNELS:%=kernels/%) $(PKG_BUILD_DIR)/install/new_kernels cp
> kernel_and_patches/doinst.sh $(PKG_BUILD_DIR)/install cd
> $(PKG_BUILD_DIR) && /sbin/makepkg -c n $(KERNEL_PATCH_PKG)
> -8<---------------------------------------------
>
> The rule to look at above is the rule for isolinux/initrd.img which
> takes the contents of initrd_src and creates your new initrd.img. If you
> have a working nano in the directory tree of initrd_src you will get
> nano on the installation disk.
>
> If initrd_src doesn't already exist it is created by unpacking the
> contents of your current isolinux/initrd.img. This unpacking with cpio
> has to be done as root to keep ownership of files in the directory tree,
> all the other targets can be built as a normal user.
>
> The Makefile above does a lot more than just creating a custom
> initrd.img, it also patches and builds kernels with different
> configurations and creates a install DVD image as well as a smaller CD
> image used for NFS installs. Your imagination is the only limit on how
> Slackware can be customized.
>
> regards Henrik
Co-incidentally, this lines up with another project I've been tinkering
with. It wouldn't make any difference to whats available from the install
disk boot up though. :(
Mike Jones
> On November 26, 2009 07:35, in alt.os.linux.slackware, Eef Hartman
> (E.J.M....@tudelft.nl) wrote:
>
>> Mike Jones <N...@arizona.bay> wrote:
>>> If you're going to have obscure stuff like joe and jove in the default
>>> install, the Nano should be in there too, to be fair about it.
>>
>> But nano (and mc) _are_ in the (13.0 probably "and before")
>> distribution (the tagfile for the "ap" set gives:
>> jed:OPT
>> joe:OPT
>> jove:OPT
>> mc:OPT
>> nano:REC
> [snip]
>
> I took the OP's request to mean to ask for Nano on the "Live system"
> part of the install DVD. Nano and Pico have been readily available as
> parts of install packages for quite some time.
Yup.
Sylvain Robitaille
> Yeah, but then the default Linux editor shouldn't be some "enhanced"
> stuff like vim.
It isn't, at least in Slackware:
: elvira[syl] ~; cat /etc/slackware-version
Slackware 13.0.0.0.0
: elvira[syl] ~; ls -l `which \vi`
lrwxrwxrwx 1 root system 5 2009-11-12 15:20 /usr/bin/vi -> elvis*
Now, Elvis is not as "plain" as some vis I've seen, but it also isn't as
"enhanced" as vim.
> I once wasted a couple hours because vim "conveniently" hid control
> characters. It turned out that the wanna-be sysadmin had edited a
> redhat /etc/init.d/ file under DOS and it had cr/lf instead of just lf
> for line endings.
That isn't uncommon, but that you wasted time fixing a RedHat system for
a wannabe sysadmin is certainly not vi's (or vim's) fault.
> The real vi on Solaris or any other "real" Unix would have shown me that
> immediately.
So would "file" have, without even requiring that you start a text
editor. For example:
: charlotte[syl] ~; cat /etc/slackware-version
Slackware 12.1.0
: charlotte[syl] ~; todos <Ethernet.txt >Ethernet_dos.txt
: charlotte[syl] ~; file Ethernet*.txt
Ethernet.txt: ASCII English text
Ethernet_dos.txt: ASCII English text, with CRLF line terminators
> Give me a plain vi any day, just not this idiotic "enhanced" crap.
For day-to-day text editting, vim is hard to beat. You don't need to use
any of the "enhanced" features. In fact, vim has a mode of operation in
which it behaves like an ordinary vi. For emergency work, especially on
an unfamiliar system, a predictable "unenhanced" vi is far more desirable.
> Plain vi is the standard, and works everywhere. vim is no better than
> nano in that it is a niche tool.
That's a silly comparison. Vim is a far more powerful editor than
Nano (I'm not knocking Nano; it's less powerful by design). However,
I'd say the Slackware distribution agrees that Vim strays too far from
"real" vi (whose vi is the real one? UCB's? I don't believe the vi
on recent versions of Solaris is UCB's, so is it the "real" vi?) to
take it's place as the default editor. What I've found works best for
me is being aware that there are multiple vi-like editors out there,
so if I'm working with one that isn't behaving as I expect, it's fairly
easy for me to reconcile that, and fall back to "plain" editing commands.
--
----------------------------------------------------------------------
Sylvain Robitaille s...@encs.concordia.ca
Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
Sylvain Robitaille
> Contrary to some occasionally amusing urban myths, Vi is not an
> editor. Its a puzzle game /disguised/ as an editor. Entertaining and
> even useful to those who have brains capable of performing the
> hoop-jumping required to pilot such a beast, but a not-very-funny
> practical joke to those who require their "OMG! Where is the text
> editor?" save-the-day tool to "just ****ing WORK FFS!" ...
In this light, think of vi as more of an entrance exam.
Nano is the remedial class! ;-)
> BTW, banging your head against a wall is not a good idea, no matter
> how many people do it, "Because the wall is there". ;\
Dumbing down something as simple as a text editor, causing those with
years (or perhaps even decades) of real experience with the power of a
proper text editor, to bang their heads against walls trying make the
crippled editor do things that are nice and simple in the real editor,
in the interest of protecting the foreheads of those more used to "edit"
or "notepad", would be perhaps "misguided".
Mike Jones
[...]
> For day-to-day text editting, vim is hard to beat. You don't need to
> use any of the "enhanced" features. In fact, vim has a mode of
> operation in which it behaves like an ordinary vi. For emergency work,
> especially on an unfamiliar system, a predictable "unenhanced" vi is far
> more desirable.
If you've had your brain rewired, maybe. For us normal mortals with
limited lifespans, its a "Raiders of the Lost Ark" puzzle game, and
typically appears in the precise situation where we need a text editor
that actually makes sense and works at least /something/ like all the
other editors we've seen and\or used. This is NOT Vi(m).
"My system might be hosed and hacking into it from the install boot is my
last option!" is NOT a good time to be faced with a "WTH?" experience
like Vi(m).
If my brain worked like that (ie: could intuitively use Vi, Ha! Now
there's a concept!), I'd have found a better way to fix things than
booting the install disk and teasing around for last options before
nuking from orbit and starting again from scratch.
No, sorry. Associating Vi (and\or clones) with "predictable" doesn't work.
Its a game. Play it, love it (maybe, if you have a capacity for that),
learn it, eventually use it. Run into it in a crisis, hate it, dump it.
For day-to-day editing, you can't beat an actual text editor. Vi isn't a
text editor, its some kind of idiosyncratic tool with text editing
functions included, and it's certainly /not/ intuitive or "predictable".
Its incantational and obscure, and full of dead ends and locked up WTF?
situation if you don't "understand" it.
Maybe its just me and a few other species similar to humans, but if I
wanted to confuse and frustrate somebody, I'd sit them down with a fixed
terminal and only Vi to get their tasks done. If I wanted to make life
hell, I'd give them a deadline too.
Crisis plus deadline plus Vi. Shudder! >:|
Dan C
> Responding to Sylvain Robitaille:
>
> [...]
>> For day-to-day text editting, vim is hard to beat. You don't need to
>> use any of the "enhanced" features. In fact, vim has a mode of
>> operation in which it behaves like an ordinary vi. For emergency work,
>> especially on an unfamiliar system, a predictable "unenhanced" vi is
>> far more desirable.
>
>
> If you've had your brain rewired, maybe. For us normal mortals with
> limited lifespans, its a "Raiders of the Lost Ark" puzzle game, and
> typically appears in the precise situation where we need a text editor
> that actually makes sense and works at least /something/ like all the
> other editors we've seen and\or used. This is NOT Vi(m).
It most certainly is, to me or anybody else who's ever taken the time to
learn how to use it.
> "My system might be hosed and hacking into it from the install boot is
> my last option!" is NOT a good time to be faced with a "WTH?" experience
> like Vi(m).
So, take the time beforehand to learn how to use it. Wow, what a concept.
> If my brain worked like that (ie: could intuitively use Vi, Ha! Now
> there's a concept!), I'd have found a better way to fix things than
> booting the install disk and teasing around for last options before
> nuking from orbit and starting again from scratch.
>
> No, sorry. Associating Vi (and\or clones) with "predictable" doesn't
> work.
You sound more clueless with every sentence you write.
> Its a game. Play it, love it (maybe, if you have a capacity for that),
> learn it, eventually use it. Run into it in a crisis, hate it, dump it.
You appear to be more of a n00b than I had thought.
> For day-to-day editing, you can't beat an actual text editor. Vi isn't a
> text editor, its some kind of idiosyncratic tool with text editing
> functions included,
OK, cluelessness confirmed.
> and it's certainly /not/ intuitive or "predictable".
> Its incantational and obscure, and full of dead ends and locked up WTF?
> situation if you don't "understand" it.
And seconded.
> Maybe its just me and a few other species similar to humans, but if I
> wanted to confuse and frustrate somebody, I'd sit them down with a fixed
> terminal and only Vi to get their tasks done. If I wanted to make life
> hell, I'd give them a deadline too.
>
> Crisis plus deadline plus Vi. Shudder! >:|
It helps to have an IQ above room temperature.
Sheesh.
Dan C
It sounds like you should just use Windoze. This Linux stuff is too hard
for you.
Keith Keller
>
> Contrary to some occasionally amusing urban myths, Vi is not an editor.
> Its a puzzle game /disguised/ as an editor.
vi is a very powerful editor once you know it. nano is an entry-level
editor. Both can be useful in their own context, and be disastrous in
the other's context. Your whinging about how difficult vi is to use is
not helpful. (And for all the joking I do about "DEATH TO EMACS!!!",
emacs is also a very powerful editor once you know it. All sysadmins
beyond beginner should learn at least one of these two editors.)
Is vi difficult to use *for a beginner*? Of course! And I would not
recommend it to everyone; I support users who will never use it, because
they have no need for it.
> So, Nano should be the default editor on EVERYTHING, including kettles.
That is like saying all cars should be 2wd automatics.
> I still use it [MC] as my default file manager. Its works nearly anywhere.
cd and ls work on every usable OS. ;-)
Keith Keller
>
> He's kind of open to dicscussion, I had talked to him about a few programs
> I think should be in it by default (such as postfix, dovecot, and I threw
> in pureftpd as well for measure), he suggested those in slackbuilds, I
> then suggested that they are very mainstream programs and it would be
> beneficial to have them in the offical release, like most every other
> distro does (at least with postfix and dovecot), I guess we'll know in
> time if he deicdes to, but since that was over a month ago and there's no
> appearance in -current I dare say he isn't going to in the near future.
Wow, learn how to split into multiple sentences!
Pat is likely reluctant to include postfix and dovecot because they
would replace sendmail and UW imapd, and he has often not wanted to pull
the rug out from people already relying on existing tools. Having these
in Slackbuilds (or extras/) makes a lot of sense. Though I can
certainly see a case for replacing the old and creaky UW imapd with
dovecot in a future major release.
Loki Harfagr
> On Thu, 26 Nov 2009 16:46:53 +0000, Mike Jones wrote:
>
>> Responding to Sylvain Robitaille:
>>
...
>
>> Maybe its just me and a few other species similar to humans, but if I
>> wanted to confuse and frustrate somebody, I'd sit them down with a
>> fixed terminal and only Vi to get their tasks done. If I wanted to make
>> life hell, I'd give them a deadline too.
>>
>> Crisis plus deadline plus Vi. Shudder! >:|
vim becomes quite useable when you help 'him' to behave, old e.g.:
$ alias vim=' vim -u NONE'
> It helps to have an IQ above room temperature.
How deceiving! until then I thought you were using the Fahrenheit scale ;->
Loki Harfagr
> On 2009-11-26, Res <r...@ausics.net> wrote:
>>
>> He's kind of open to dicscussion, I had talked to him about a few
>> programs I think should be in it by default (such as postfix, dovecot,
>> and I threw in pureftpd as well for measure), he suggested those in
>> slackbuilds, I then suggested that they are very mainstream programs
>> and it would be beneficial to have them in the offical release, like
>> most every other distro does (at least with postfix and dovecot), I
>> guess we'll know in time if he deicdes to, but since that was over a
>> month ago and there's no appearance in -current I dare say he isn't
>> going to in the near future.
>
> Wow, learn how to split into multiple sentences!
Well, Res is too much used to directly 'speak' in .m4 ;-)
>
> Pat is likely reluctant to include postfix and dovecot because they
> would replace sendmail and UW imapd, and he has often not wanted to pull
> the rug out from people already relying on existing tools.
I second this advice and I also second the opinion and also
mostly second the following opinion ,-)
> Having these
> in Slackbuilds (or extras/) makes a lot of sense. Though I can
> certainly see a case for replacing the old and creaky UW imapd with
> dovecot in a future major release.
Note please that UW may be creaky because old but not so crappy and
it's only since version 1.1+ that dovecot is making a clean test
while the oldie UW was still quite "correct" :-)
(synth. report on http://imapwiki.org/ImapTest/ServerStatus)
Now, for the SMTP part (which weighs around 3/4 of my work) all I
can say is that at the time I had to make the choice for a "distro"
when the client wanted FLOSS I chosed Slackware not only because
it was quite close to BSD (discarded at the time just because none
of their flavor had support for the cpq array included in the
servers already bought by the company section which was in
charge of these usual recurrent mistakes in the order of events
and ordered before the events) AND it bear the full clean sendmail
instead of the other main "distros" which at the time went
fuzzy in the knees and jumped on trends like posfix or
exim or even more unusable unsignificant others ,->
So, I'm not against the idea of a postfix extra package but the
main line must keep solid.
Of course this advice may change when sm-X will out but
until then that's still speculations on a moving specs spectre.
Keith Keller
>
> Note please that UW may be creaky because old but not so crappy and
> it's only since version 1.1+ that dovecot is making a clean test
> while the oldie UW was still quite "correct" :-)
> (synth. report on http://imapwiki.org/ImapTest/ServerStatus)
Perhaps, but at my last check, UW imapd did not support Maildir format,
which means it didn't support subfolders, which means it was not usable
for my purposes. Since I haven't received any complaints about dovecot
in over five years, I have to assume that they never hit the bugs
mentioned on that page.
> Now, for the SMTP part (which weighs around 3/4 of my work)
For SMTP, I actually prefer postfix, and I install it separately when I
use Slackware. But I am only one user, and one who doesn't have an
existing Sendmail installation, at that; those Slackware users take
priority over users like me, IMO.
> So, I'm not against the idea of a postfix extra package but the
> main line must keep solid.
Agreed ATM. But things always change. Remember when people were
against Slackware dropping support for floppy disk images? ;-)
notbob
Trim yer damn posts!
notbob
> ......think of vi as more of an entrance exam.
Think of vi as an editor for tards! What moron would use an editor
that requires extra keystokes to change modes just to edit?
"vi, heart of evil" --notbob
nb
Joe
> On Wed, 25 Nov 2009 18:12:03 -0800, Joe wrote:
>
>> Yeah, but then the default Linux editor shouldn't be some "enhanced"
>> stuff like vim.
>
> It isn't, at least in Slackware:
True that.
>> I once wasted a couple hours because vim "conveniently" hid control
>> characters. It turned out that the wanna-be sysadmin had edited a
>> redhat /etc/init.d/ file under DOS and it had cr/lf instead of just lf
>> for line endings.
>
> That isn't uncommon, but that you wasted time fixing a RedHat system for
> a wannabe sysadmin is certainly not vi's (or vim's) fault.
:-)
I should have installed Slackware, I know ;-)
>> The real vi on Solaris or any other "real" Unix would have shown me that
>> immediately.
>
> So would "file" have, without even requiring that you start a text
> editor. For example:
>
> : charlotte[syl] ~; cat /etc/slackware-version
> Slackware 12.1.0
> : charlotte[syl] ~; todos <Ethernet.txt >Ethernet_dos.txt
> : charlotte[syl] ~; file Ethernet*.txt
> Ethernet.txt: ASCII English text
> Ethernet_dos.txt: ASCII English text, with CRLF line terminators
Yeah, I know. Hindsight is 20/20.
But in that situation, you have to get the idea first that the line endings are
the problem. We were troubleshooting the configuration, not the file it was in.
>> Give me a plain vi any day, just not this idiotic "enhanced" crap.
>
> For day-to-day text editting, vim is hard to beat. You don't need to use
> any of the "enhanced" features. In fact, vim has a mode of operation in
> which it behaves like an ordinary vi. For emergency work, especially on
> an unfamiliar system, a predictable "unenhanced" vi is far more desirable.
>
>> Plain vi is the standard, and works everywhere. vim is no better than
>> nano in that it is a niche tool.
>
> That's a silly comparison. Vim is a far more powerful editor than
> Nano (I'm not knocking Nano; it's less powerful by design). However,
> I'd say the Slackware distribution agrees that Vim strays too far from
> "real" vi (whose vi is the real one? UCB's? I don't believe the vi
> on recent versions of Solaris is UCB's, so is it the "real" vi?) to
> take it's place as the default editor. What I've found works best for
> me is being aware that there are multiple vi-like editors out there,
> so if I'm working with one that isn't behaving as I expect, it's fairly
> easy for me to reconcile that, and fall back to "plain" editing commands.
>
Any vi that doesn't by default (sure, it can always be changed, but the default
is what you are most likely to see) hide control characters.
-Joe
Joe
> Responding to Sylvain Robitaille:
>
> [...]
>> For day-to-day text editting, vim is hard to beat. You don't need to
>> use any of the "enhanced" features. In fact, vim has a mode of
>> operation in which it behaves like an ordinary vi. For emergency work,
>> especially on an unfamiliar system, a predictable "unenhanced" vi is far
>> more desirable.
>
>
> If you've had your brain rewired, maybe. For us normal mortals with
> limited lifespans, its a "Raiders of the Lost Ark" puzzle game, and
> typically appears in the precise situation where we need a text editor
> that actually makes sense and works at least /something/ like all the
> other editors we've seen and\or used. This is NOT Vi(m).
Then you learn it.
When you have to fix somebody else's system, you don't have the time to install
another editor. You make do with what is there. And that always is vi.
> Crisis plus deadline plus Vi. Shudder! >:|
That what you get. Live with it.
In a crisis, you don't have the time to install some other editor. So, you
better learn how to use vi, and be done with it.
-Joe
Sylvain Robitaille
(referring to vi and emacs)
> ... All sysadmins beyond beginner should learn at least one of these
> two editors.)
Agreed, and should be able to at least be functionally familiar with
the other. Sysadmins _at_ the "beginner" stage should be aiming to
acquire at least basic functional knowledge of at least one of the two,
and expecting to eventually do the same for the other.
When I started as a sysadmin some years ago, I used and liked Emacs for
all my text editing. I had come from a Wordstar (and Wordstar-like)
environment prior to that, so I took to Emacs relatively easily.
I didn't understand why anyone would want to use vi for anything other
than when absolutely necessary. I had, at that time, as a workstation,
a DecStation 1200, running NetBSD. Anyone even remotely familiar with
these systems likely will understand how at some point it occured to
me how little sense there was in launching Emacs every time I wanted
to make minor edits to simple files. And so I became more and more
comfortable with vi to the point where I was using it by default and
using Emacs only when I wanted some enhanced feature that either I
couldn't or didn't know how to get in vi.
Then I saw colleagues doing some things with vim that I'd been wishing
I could figure out how to do with Emacs (let alone vi). I don't even
bother installing Emacs on my own systems any more, and if I were in a
position where it was the only editor available, I likely could still
fumble my way through basic editing, but certainly nothing advanced.
That said, some of vim's "features" annoy me, so they're explicitly
disabled in my .vimrc. The ability to do that is, of course, the best
feature of the editor.
Joe
> Lew Pitcher <lewpi...@lewpitcher.ca> wrote:
>> If you want to think in a minimal, survivalist manner, you should
>> lookup the "ex" command.
>
> If you really wanna go minimal, look up "ed" (i.e. the stream editor,
> sed, is derived from THAT, nor from the EXtended editor ex).
sed is really powerful, with regex. I use it regularly in my scripts (I have to
write multiline documentation, though, to be able remember 6 months later what
the one-line regex does...)
-Joe
Joe (Immigration)
> On Thu, 26 Nov 2009 12:28:17 GMT, Mike Jones wrote:
>
>> Contrary to some occasionally amusing urban myths, Vi is not an
>> editor. Its a puzzle game /disguised/ as an editor. Entertaining and
>> even useful to those who have brains capable of performing the
>> hoop-jumping required to pilot such a beast, but a not-very-funny
>> practical joke to those who require their "OMG! Where is the text
>> editor?" save-the-day tool to "just ****ing WORK FFS!" ...
>
> In this light, think of vi as more of an entrance exam.
>
> Nano is the remedial class! ;-)
LOL. You are not a real *nix admin if you don't know vi...
Sylvain Robitaille
>> : charlotte[syl] ~; file Ethernet*.txt
>> Ethernet.txt: ASCII English text
>> Ethernet_dos.txt: ASCII English text, with CRLF line terminators
>
> But in that situation, you have to get the idea first that the line
> endings are the problem. We were troubleshooting the configuration,
> not the file it was in.
Experience goes a long way, I think. If you're troubleshooting a
configuration, and you don't *see* anything that seems wrong, it's time
to look for anything wrong that you don't "see". file and od become
very valuable tools at that point.
Also, in its default configuration, vim will identify the file as "DOS"
formatted, on the status line at the bottom, so you still could have
seen that before much of your time had been wasted:
My example above shows the following when opened in vim:
"Ethernet_dos.txt" [dos] 1695L, 65201C 1,1 Top
Lew Pitcher
> Dan C wrote on 11/25/09 13:59:
>> Did you miss the part about 'vi' being the de facto standard unix
>> text editor, which will nearly always be available on any *nix
>> system? Not knowing how to use it does yourself a disservice.
>> What will you do if someday you are called upon to fix/edit a
>> real Unix system?
> Yeah, but then the default Linux editor shouldn't be some
> "enhanced" stuff like vim.
The standard unix text editor is ex, not vi.
LewPi...@LewPitcher.ca
--
Official Website -->> http://lewpitcher.ca/
Something to look at: -->> http://www.emusclemag.com/
Lonely in Brampton? -->> http://gaypros.meetup.com/cities/ca/on/brampton/
Peel HIV/AIDS Network -->> http://www.phan.ca/home.html
Lew Pitcher
> On Wed, 25 Nov 2009, Mike Jones wrote:
>
>>>> Reqest to Slackware installation media developers:
>>> That would be volk...@slackware.com
>> If one wanted to clog up Pat's email with such trivialities. Simple
>> posting to this NG should act as a low priority message-in-a-bottle.
> Nope, Pat does not read this NG, its full of wankers so why would he :)
> Pat alone has the only say of what goes into Slackware.
Who is "Pat?" Are you referring to Mr. Volkerding? Would you have
us believe that you are on a firstname basis?
You have no idea whether "Pat" reads this group. In fact, when he
gets up in the morning "Pat" has no idea what he is going to end up
reading that day.
You are a small impotent little troll, seeking recognition through
implied association with the writer of an old, small, and
essentially failed, linux distribution.
Lew Pitcher
> Contrary to some occasionally amusing urban myths, Vi is not an editor.
> Its a puzzle game /disguised/ as an editor. Entertaining and even useful
> to those who have brains capable of performing the hoop-jumping required
> to pilot such a beast, but a not-very-funny practical joke to those who
> require their "OMG! Where is the text editor?" save-the-day tool to "just
> physically damaged hardware. Emacs, to take this to extremes, is just
> sadism in software form, or masochism, if you're into that kind of thing.
Actually, vi is a mode of the ex editor.
> So, Nano should be the default editor on EVERYTHING, including kettles.
No, nano is junk and everyone knows it.
Use mcwrite or joe if you aren't willing to use vim.
Lew Pitcher
>
> For day-to-day text editting, vim is hard to beat. You don't need to use
> any of the "enhanced" features. In fact, vim has a mode of operation in
> which it behaves like an ordinary vi. For emergency work, especially on
> an unfamiliar system, a predictable "unenhanced" vi is far more desirable.
And allow us to add that for "day-to-day" coding vim can't be beat.
You can shove your typical IDEs where the sun don't shine.
> That's a silly comparison. Vim is a far more powerful editor than
> Nano (I'm not knocking Nano; it's less powerful by design). However,
> I'd say the Slackware distribution agrees that Vim strays too far from
> "real" vi (whose vi is the real one? UCB's? I don't believe the vi
> on recent versions of Solaris is UCB's, so is it the "real" vi?) to
> take it's place as the default editor. What I've found works best for
> me is being aware that there are multiple vi-like editors out there,
> so if I'm working with one that isn't behaving as I expect, it's fairly
> easy for me to reconcile that, and fall back to "plain" editing commands.
There is no reason to learn more than one editor. And vim (or gvim)
fills all needs. But if, for some reason vim is not readily
available then mc write, joe, and our long-time fave le, are the way
to go.
The only reason emacs is in a separate directory on the installation
DVD is so that it does not have to be loaded at installation time.
We are currently lobbying the Federal Government to make it legal to
pulp the skulls, with a baseball bat, of all emacs "enthusiasts."
Joe
> On Thu, 26 Nov 2009 12:06:29 -0800, Joe wrote:
>
>>> : charlotte[syl] ~; file Ethernet*.txt
>>> Ethernet.txt: ASCII English text
>>> Ethernet_dos.txt: ASCII English text, with CRLF line terminators
>> But in that situation, you have to get the idea first that the line
>> endings are the problem. We were troubleshooting the configuration,
>> not the file it was in.
>
> Experience goes a long way, I think. If you're troubleshooting a
> configuration, and you don't *see* anything that seems wrong, it's time
> to look for anything wrong that you don't "see". file and od become
> very valuable tools at that point.
od was indeed what revealed the problem...
> Also, in its default configuration, vim will identify the file as "DOS"
> formatted, on the status line at the bottom, so you still could have
> seen that before much of your time had been wasted:
Not at that time, I guess (this was 10 years ago or so.)
-Joe
Mike Jones
And never EVER allow the streams to get crossed... ;\
Mike Jones
> Trim yer d
Ok.
--
sig
Mike Jones
Or, alternatively, boot a different SNAFU disk, like "rescuecd".
You missed the "free choice" lecture on the FOSS course, didn't you? ;)
T'would have been nice to be able to just use the Slack disk, but... :\
Mike Jones
> On Thu, 26 Nov 2009 12:28:17 GMT, Mike Jones wrote:
>
>> Contrary to some occasionally amusing urban myths, Vi is not an editor.
>> Its a puzzle game /disguised/ as an editor. Entertaining and even
>> useful to those who have brains capable of performing the hoop-jumping
>> required to pilot such a beast, but a not-very-funny practical joke to
>> those who require their "OMG! Where is the text editor?" save-the-day
>> tool to "just ****ing WORK FFS!" ...
>
> In this light, think of vi as more of an entrance exam.
>
> Nano is the remedial class! ;-)
Except being faced with an entrance exam when looking at a barfed system
is not productive. Once needs an editor to /actually edit/ as at least
its /default function/ at this time. And don't get me started on the Vim
help that dosn't tell you how to exit help! Like I said, its a puzzle
game with a hidden editor built in (so I'm told).
>> BTW, banging your head against a wall is not a good idea, no matter how
>> many people do it, "Because the wall is there". ;\
>
> Dumbing down something as simple as a text editor, causing those with
> years (or perhaps even decades) of real experience with the power of a
> proper text editor, to bang their heads against walls trying make the
> crippled editor do things that are nice and simple in the real editor,
> in the interest of protecting the foreheads of those more used to "edit"
> or "notepad", would be perhaps "misguided".
There is a world of difference between "dumbed down" and "just works".
To learn how Vi works, you need it's help system, which doesn't tell you
how the help system works, or how to exit the help system, or even how to
actually EDIT something. Like I said, its a possibly puzzle game, not a
"Damn! I need some kind of editor and fast!" solution.
Mike Jones
My point in a nutshell. I'm not a sysadmin. I'm an enthusiastic dabbler.
Vi (and clones) are like learning to speak Russian to me. Sure, I /could/
do it, but how many times am I going to meet a Russian who can't get by
in English? My only "Russian" encounter is when I want to do a hack edit
from a bootable media and stick a Slack disk in the slot. We now have
stuff like RescueCD. Therefore, I still don't need to learn the obscure
and incantational mysteries of an editor that doesn't edit unless you
know the hidden magic spells, (and hidden they are to be sure).
Ah well. Back to Nano, which incidentally, my cat learned to use. ;)
Aaron W. Hsu
>Lew Pitcher <lewpi...@lewpitcher.ca> wrote:
>> If you want to think in a minimal, survivalist manner, you should
>> lookup the "ex" command.
>If you really wanna go minimal, look up "ed" (i.e. the stream editor,
>sed, is derived from THAT, nor from the EXtended editor ex).
Indeed. Actually Ed has saved me a number of times even when Vi was
available, because Vi is still a full screen editor, and sometimes your
terminal is so messed up that you can't work with editors that aren't
purely line based with almost no interface. All installations should
have ed installed.
Aaron W. Hsu
Aaron W. Hsu
>Something as small as Nano = no, but Vi, which is huge (and complex) by
>comparison, is the standard? From the installation disk boot? This
>doesn't add up.
If you want a small editor, and a minimalist installer that is quick and
easy to use, then why not look at the OpenBSD installer, which recently
had several improvements made for it, and which doesn't even include Vi,
but rather, uses ed, which is about as lightweight as you can get.
Aaron W. Hsu
Aaron W. Hsu
>Mike Jones wrote:
>> Something as small as Nano = no, but Vi, which is huge (and complex)
>> by comparison, is the standard? From the installation disk boot? This
>> doesn't add up.
>Nano is about five times bigger than standard vi (in disksize, in
>functionality vi is about 100 times "bigger"):
>[dakini]~$ ls -l /usr/bin/nano /usr/bin/nvi
>-rwxr-xr-x 1 root root 145884 2008-09-16 02:07 /usr/bin/nano
>-rwxr-xr-x 3 root root 30354 2009-04-05 15:39 /usr/bin/nvi
Ed ought to be considered too:
-rwxr-xr-x 1 root root 49408 2009-06-12 17:01 /bin/ed*
-rwxr-xr-x 1 root root 522496 2008-09-23 15:35 /usr/bin/elvis*
-rwxr-xr-x 1 root root 179480 2009-05-23 00:48 /usr/bin/nano*
Aaron W. Hsu
Keith Keller
>
> Except being faced with an entrance exam when looking at a barfed system
> is not productive.
Unless you barf your system inside the first month or so, you should
know enough vi to manage by then.
> Like I said, its a puzzle
> game with a hidden editor built in (so I'm told).
You have said this way too many times to be credible.
Please read this before complaining about vim again.
http://blog.interlinked.org/tutorials/vim_tutorial.html
(Sadly, "elvis tutorial" didn't turn up what you might hope for from
Google. So cruel.)
Lew Pitcher
> My point in a nutshell. I'm not a sysadmin. I'm an enthusiastic dabbler.
Exactly. You are a hobbyist, as is everyone who posts to this ng
who is below the age of 35. Those older than 35 probably learned
unix on a real system and slackware when there were few linux
alternatives.
Others, like Coward Hicks, Keith Wellar, and other junior pukes,
pursue slackware because they think, laughably, that learning the
effectively obsolete bash shell teaches one more about the OS than
learning the modern gui.
We laugh at these clowns because they don't know the difference
between an OS and a shell.
Lew Pitcher
> Eef Hartman <E.J.M....@tudelft.nl> writes:
>>If you really wanna go minimal, look up "ed" (i.e. the stream
>>editor, sed, is derived from THAT, nor from the EXtended editor
>>ex).
> Indeed. Actually Ed has saved me a number of times even when Vi
> was available, because Vi is still a full screen editor, and
> sometimes your terminal is so messed up that you can't work with
> editors that aren't purely line based with almost no interface.
> All installations should have ed installed.
That is where you should be using ex, not ed. ed edits basic
streams editor while ex is a basic text editor. Try typing "vi"
from ex and ed to see the difference.
Lew Pitcher
ed does not use the same commands as vi or ex. That is why ex is
better. Unfortunately ex is linked to vim on our system...so that
kind of shatters the smaller size myth.
But if your screen will only support a line editor, then ex, not ed,
is your best bet.
Lew Pitcher
But ed requires libraries. There are several tiny editors around
that do not require a library - there is one called "q" if I recall
correctly, and these are more ideal for a rescue disk.
Henrik Carlqvist
> is this Makefile available somewhere in the Net?
Yes and no. Yes, I have posted it in this newsgroup (also some time
earlier if I remember right) to be copied by interested people. No, as far
as I know it is not available for download as a single file by ftp or http.
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost
Henrik Carlqvist
> Then I saw colleagues doing some things with vim that I'd been wishing
> I could figure out how to do with Emacs
Even though this thread has since long left its initial purpose I get
curios. Do you have any quick example of some of those things vi can do?
regards Henrik (who only knows how to use vi for basic editing and mostly
uses emacs)
Henrik Carlqvist
>> PS: the ls, rm, cp and e.g. grep and gunzip commands are in busybox too,
>> Pat _is_ using a separate "tar" executable, but there is a minimal tar
>> in busybox too).
> Ah. This is a different situation to just sticking a text editor into a
> dir then.
Yes, but the fact that most commands are built into busybox does not mean
that all commands have to be there. If you want some extra commands you
can put some files in the initrd as I wrote earlier. However, it might not
be enough to only put an executable file there, you might need some
dynamic libraries also.
And yes, the more "bloat" a wanted feature needs in the standard install
disk the less likelyhood that it will pass Pats final word on the decision
whether it will be included.
regards Henrik
Grant
>Mike Jones <N...@Arizona.Bay> wrote:
>>> PS: the ls, rm, cp and e.g. grep and gunzip commands are in busybox too,
>>> Pat _is_ using a separate "tar" executable, but there is a minimal tar
>>> in busybox too).
>
>> Ah. This is a different situation to just sticking a text editor into a
>> dir then.
>
>Yes, but the fact that most commands are built into busybox does not mean
>that all commands have to be there. If you want some extra commands you
>can put some files in the initrd as I wrote earlier. However, it might not
>be enough to only put an executable file there, you might need some
>dynamic libraries also.
Perhaps a static-linked version of the desired binary? But I would think
most people spend very little time in the installer.
I met vi same time I met unix -- there's less than a dozen keystrokes to
be learned for basic editing, I don't see the hassle in remembering that.
And one's left little finger soon streches the extra inches needed to
reach the escape key ;^)
I usually rewrite /mnt/etc/lilo.conf during each new install, but leave
editing /etc/fstab and other .conf files until after the first boot.
On a new system first things copied from the file server (once I get nfs
access) are custom .vimrc and .bash* files, the ~/.ssh/authorized_keys
for root and user, and my kernel build scripts.
Then I have vim tamed, and only meet vi in its other roles as 'crontab -e'
and visudo -- what do the nano, pica people do here?
Grant.
--
http://bugsplatter.id.au
Helmut Hullen
Du meintest am 27.11.09:
> Then I have vim tamed, and only meet vi in its other roles as
> 'crontab -e' and visudo -- what do the nano, pica people do here?
a) a definition
VISUAL=/bin/mcedit
EDITOR=/bin/mcedit
export VISUAL EDITOR
in "/etc/profile.d" and/or "~/.profile"
or
b)
VISUAL=/usr/bin/mcedit crontab -e
VISUAL=/bin/ed visudo
VISUAL=/usr/bin/nano vipw
on the CLI.
If "VISUAL" is not set as an environment variable you can use
EDITOR=/usr/bin/mcedit crontab -e
etc. on the CLI.
Maybe you have to define
Defaults editor=/usr/bin/mcedit /usr/bin/nano /bin/ed
Defaults env_editor
in your "/etc/sudoers".
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Grant
>Hallo, Grant,
>
>Du meintest am 27.11.09:
>
>> Then I have vim tamed, and only meet vi in its other roles as
>> 'crontab -e' and visudo -- what do the nano, pica people do here?
>
>a) a definition
> VISUAL=/bin/mcedit
> EDITOR=/bin/mcedit
> export VISUAL EDITOR
>
>in "/etc/profile.d" and/or "~/.profile"
>
>or
>
>b)
>
> VISUAL=/usr/bin/mcedit crontab -e
> VISUAL=/bin/ed visudo
> VISUAL=/usr/bin/nano vipw
>
>on the CLI.
>
>If "VISUAL" is not set as an environment variable you can use
>
> EDITOR=/usr/bin/mcedit crontab -e
Hey I just tried that and it came up in elvis! (And one exits
vi's help the same as quitting a document, with :q, seems quite
natural to me :)
~$ which mcedit
/usr/bin/mcedit
This leaves me a bit doubtful now about the other vi alternatives you
gave?
>
>etc. on the CLI.
>
>Maybe you have to define
>
> Defaults editor=/usr/bin/mcedit /usr/bin/nano /bin/ed
> Defaults env_editor
>
>in your "/etc/sudoers".
Erk! And all that easier than remembering 'i', <esc> and :wq for vi?
Each to their own :)
Grant.
--
http://bugsplatter.id.au
Mike Jones
The key here is not so much how big the editor is, but how usable it is
to somebody who just needs an editor that works which doesn't need an
extended course in incantational keysets just to edit a ****ing text file
or two.
Vi is like a full commercial flight simulator with realistic accident
generation capacity built in, and ed is a legacy example of just why so
many people developed editors that were nothing like ed.
Thanks for the tip, but its not that useful under the circumstances.
As a result of the input on this thread, its my conclusion that the
Slackware install DVD isn't a viable recovery resource. I'll use RescueCD
instead.
Cheers.
Helmut Hullen
Du meintest am 27.11.09:
> Hey I just tried that and it came up in elvis! (And one exits
> vi's help the same as quitting a document, with :q, seems quite
> natural to me :)
Which of my 2 versions have you tried?
What tells
echo $VISUAL
echo $EDITOR
> ~$ which mcedit
> /usr/bin/mcedit
> This leaves me a bit doubtful now about the other vi alternatives you
> gave?
On my machines both alternatives work fine.
>> Maybe you have to define
>>
>> Defaults editor=/usr/bin/mcedit /usr/bin/nano /bin/ed
>> Defaults env_editor
>>
>> in your "/etc/sudoers".
> Erk! And all that easier than remembering 'i', <esc> and :wq for vi?
Sure!
I define one time the entries for "/etc/sudoers", I define one time the
entries for "/etc/profile.d/editor.sh", and after that (small) work I
never need to remember the vi syntax.
Ok - I need "wq" for exiting the "ed" editor. But that's nearly the same
syntax as in (p.e.) "fdisk".
Mike Jones
> Martin Schmitz <ne...@rmz.ath.cx> writes:
No, it shouldn't. The other detail that got snipped was useability. Ed is
even worse than Vi for the "WTF?" factor I mentioned earlier. Therefore,
its a nogo.
Mike Jones
> On 2009-11-27, Mike Jones <N...@Arizona.Bay> wrote:
>>
>> Except being faced with an entrance exam when looking at a barfed
>> system is not productive.
>
> Unless you barf your system inside the first month or so, you should
> know enough vi to manage by then.
>
>> Like I said, its a puzzle
>> game with a hidden editor built in (so I'm told).
>
> You have said this way too many times to be credible.
>
> Please read this before complaining about vim again.
>
> http://blog.interlinked.org/tutorials/vim_tutorial.html
>
> (Sadly, "elvis tutorial" didn't turn up what you might hope for from
> Google. So cruel.)
>
> --keith
You're missing the point by a mile here.
Ok, so assume the role of "not a sysadmin" (ie: end-user with few clues)
and imagine you have a glitched system and need to do a spot of text
hacking, say, to remove the root password from /etc/shadow (as in "I
forgot my root password! Help!").
The only time you looked at Vi(m) you said "WTF is this load of junk?"
and moved on (probably now using Nano, because it makes sense from the
get go). Now, at the point where you've already booted from the Slack
install DVD, mounted up your glitched partition, and need an editor,
you're faced not with something that edits, but something that doesn't.
Now is NOT a good time to try to access the internet (can't be done until
system is fixed, ok?) and spend the afternoon learning how to operate
this incantational puzzle /before/ you can do the simple 1-shot editing
you needed to do. Right now you need an editor that edits, and does it
simply and directly, without several layers of "What the **** did it just
do?" and "How the **** do I make this thing work like an editor?"
For this purpose, Vi not only fails dismally, but actually places the
wannabe repair guy in a no-win situation.
I can understand how those who investigated Vi and found it to be a
useful tool would see how it could be /their/ ideal solution in a SNAFU
firefight, but to those who didn't take to it, and those who couldn't see
the point in adding unecessarily to their "Linux learning curve", Vi is
just a tedious joke, to be avoided, that appears like a bad joke right at
the point they needed an editor that made sense without having to learn
yet more incantational stuff just to edit a damn text file.
FWIW here, I installed Vim again, just to see if my initial reactions to
it might have been biased by first (and second, and third, yes I tried it
several times already) impressions. They weren't. Its obscure,
incantational (no apologies for repeating that one), anything but
intuitive, and so packed with false clues and illogical dead ends its not
fit for purpose unless one has indeed spent some time following the
extensive "How to use this application" course. HAVING to use such a
course just perform a simple text editing task is surely a big fat hairy
clue that Vi is NOT a application for the faint hearted, or those who
expect an application to behave like its descriptor. Vi does NOT behave
like a text editor. It behaves like Vi. There is a significant difference
there, one that puts Vi outside consideration when there are way faster
ways of resolving a simple text editing problem.
BTW, As you missed this one several times now, I'd suggest that you hold
back on making jibes about credibility here. You're drifting into a "My
fav app" flame-war position.
Ta.
Helmut Hullen
Du meintest am 27.11.09:
> No, it shouldn't. The other detail that got snipped was useability.
> Ed is even worse than Vi for the "WTF?" factor I mentioned earlier.
> Therefore, its a nogo.
Usability?
I like to use "ed" when I have to change configuration files etc. with a
script.
I don't like using "ed" inter-active.
Eef Hartman
> Since I haven't received any complaints about dovecot
> in over five years, I have to assume that they never hit the bugs
> mfor my purposes. entioned on that page.
I don't know about the current versions but dovecot 0.99.14 was -
as a imap4 server - a total piece of sh*t, it kept on currupting its
own index files, thus either NOT sending new mail, or doubly sending
old ones.
This was on a mail server (Fedora), set up by the predessor of my
colleague, which we are gradually retiring, so there is no use in
updating that system.
From the log OF that system:
imap(admin): Nov 26 15:44:29 Error: IndexID mismatch for modify log file /home/admin/Mail//.imap/Trash/.imap.index.log
imap(admin): Nov 26 15:45:03 Error: Corrupted binary tree file /home/admin/Mail//.imap/INBOX/.imap.index.tree: UID to be inserted isn't hi
gher than existing (133 <= 134)
imap(admin): Nov 26 15:45:03 Error: Corrupted binary tree file /home/admin/Mail//.imap/INBOX/.imap.index.tree: UID to be inserted isn't hi
gher than existing (134 <= 134)
imap(admin): Nov 27 07:55:08 Error: Corrupted binary tree file /home/admin/Mail//.imap/INBOX/.imap.index.tree: UID to be inserted isn't hi
gher than existing (139 <= 152)
imap(admin): Nov 27 07:55:08 Error: Corrupted binary tree file /home/admin/Mail//.imap/INBOX/.imap.index.tree: Tried to update nonexisting
UID 132
imap(chunyang): Nov 27 09:45:46 Error: Error indexing mbox file /home/chunyang/Mail//Sent: LF not found where expected
etc etc
--
*******************************************************************
** Eef Hartman, Delft University of Technology, dept. SSC/ICT **
** e-mail: E.J.M....@tudelft.nl - phone: +31-15-278 82525 **
*******************************************************************
Aaron W. Hsu
>Mike Jones <N...@arizona.bay> trolled:
>
>> My point in a nutshell. I'm not a sysadmin. I'm an enthusiastic dabbler.
>Exactly. You are a hobbyist, as is everyone who posts to this ng
>who is below the age of 35. Those older than 35 probably learned
>unix on a real system and slackware when there were few linux
>alternatives.
Humph. Says you.
Aaron W. Hsu
Aaron W. Hsu
>That is where you should be using ex, not ed. ed edits basic
>streams editor while ex is a basic text editor. Try typing "vi"
>from ex and ed to see the difference.
No, I mean, quite intentionally, ed. Ex is a line oriented mode of the
vi "suite" if you want to call it that, but I meant ed. Ex is mostly
functionally equivalent at that point, but sometimes, you don't have
access to Vi/Ex. :-)
Aaron W. Hsu
Aaron W. Hsu
>But if your screen will only support a line editor, then ex, not ed,
>is your best bet.
Maybe if you are used to it and you have it available. I still prefer ed
for those tasks, because I learned ed before Ex.
Aaron W. Hsu
Aaron W. Hsu
>But ed requires libraries. There are several tiny editors around
>that do not require a library - there is one called "q" if I recall
>correctly, and these are more ideal for a rescue disk.
I only see ed linked against libc.
Aaron W. Hsu
Aaron W. Hsu
>I met vi same time I met unix -- there's less than a dozen keystrokes to
>be learned for basic editing, I don't see the hassle in remembering that.
>And one's left little finger soon streches the extra inches needed to
>reach the escape key ;^)
Or you get yourself a keyboard that has the ESC key in a convenient
location.
Aaron W. Hsu
Lew Pitcher
(arcfide@local) wrote:
Remember, Roger loves yanking people's chains. :-)
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------
Aaron W. Hsu
>The key here is not so much how big the editor is, but how usable it is
>to somebody who just needs an editor that works which doesn't need an
>extended course in incantational keysets just to edit a ****ing text file
>or two.
If you have enough knowledge to boot into a CD, and actually *recover*
things through a rescue CD, which means you need to know command line
and some other aspects of the Linux system that some people don't have
to know, then you should definitely be able to handle switching to a
different editor, especially when it really isn't that hard to use at
the basic level.
If all you want to do is wipe the thing clean, then you don't have to
bother with the text editor at all.
Aaron W. Hsu
Aaron W. Hsu
>No, it shouldn't. The other detail that got snipped was useability. Ed is
>even worse than Vi for the "WTF?" factor I mentioned earlier. Therefore,
>its a nogo.
Do you know how to use Vi? You want nano to be there, I understand that,
because you like it for this task, but the other question I haven't seen
answered is whether you actually *know* how to navigate around with Vi
or if you really have absolutely no idea.
Aaron W. Hsu
Lew Pitcher
(arcfide@local) wrote:
Anyway, Roger is wrong. While ed, as delivered in the Slackware package,
requires libraries, there is no reason that ed /must be/ compiled to
require libraries; it is easy enough to static link all the required
libraries directly into the binary, and have a "stand alone" ed.
You can use this technique on most utilities; the only tradeoff is that the
size of the resulting binary is larger than the dynamic linked version.
Many Unix and Unix-like systems provide (or provided) static linked
binaries in the /sbin and /bin directories, just to cover the case where a
sysadmin needed to fix a system that had lost some of it's libraries.
Aaron W. Hsu
>You're missing the point by a mile here.
>Ok, so assume the role of "not a sysadmin" (ie: end-user with few clues)
>and imagine you have a glitched system and need to do a spot of text
>hacking, say, to remove the root password from /etc/shadow (as in "I
>forgot my root password! Help!").
[...]
>For this purpose, Vi not only fails dismally, but actually places the
>wannabe repair guy in a no-win situation.
If this is the situation you suggested, then they won't know about the
/etc/passwd file. This means that they will be following some guide.
This also means that they should be chrooting into their system as soon
as they can. It's a simple command, and it gets you all your old
software, including nano. If you are able to mount and get into the
system, and all you have to do is change a few files, then there's
nothing hard here, and in fact, single-user mode is probably more useful
than a recovery disk for this.
Either way, you get nano, and the recovery disk does not have to change.
Aaron W. Hsu
Sylvain Robitaille
> You're missing the point by a mile here.
Actually, I think you're the one who apparently insists on missing
others' points. Your point is that vi(m) is too obtuse to learn how
to use at the moment you need it most. Others have tried to make the
point that you *could* learn how to use it *before* that moment, and
spare yourself any agony. You insist on responding to that by pointing
out it's too obtuse to learn how to use when you need it most. See the
problem?
> Ok, so assume the role of "not a sysadmin" (ie: end-user with few
> clues) and imagine you have a glitched system and need to do a spot of
> text hacking, say, to remove the root password from /etc/shadow (as in
> "I forgot my root password! Help!").
"end-user with few clues" does not need the root password. Is the
person a sysadmin (has need for the root password) or not (no need for
the root password)? If a person is a sysadmin, it behooves them to
learn to use the tools available to them. If they're a wannabe
sysadmin, they need to accept that there will be times when they'll just
be in over their heads and they need someone else's help. Hopefully
those times won't be based around the simple need to edit a text file
when the tools are indeed available ...
> The only time you looked at Vi(m) you said "WTF is this load of junk?"
> and moved on ....
I sense this scenario is at least in part autobiographical ...
> Now, at the point where you've already booted from the Slack install
> DVD, mounted up your glitched partition, and need an editor, you're
> faced not with something that edits, but something that doesn't.
There aren't any text editors on the installation, which in your
scenario above, is mounted and waiting for a simple edit to the shadow
file?
> For this purpose, Vi not only fails dismally, but actually places the
> wannabe repair guy in a no-win situation.
Well, no. Not if the wannabe repair guy has sufficient knowledge of
the tools available on the system he's trying to repair. What editors
are installed on the system being repaired. Could they not be used once
that system is mounted from the running installation CD?
> FWIW here, I installed Vim again, ...
Start simple. Explore Elvis ("vi" on a stock Slackware installation).
Gain some basic functional familiarity with it. You can apply that to vim
(or to other vi-like editors) later if you want to, but what you want
to start with is "basic" vi. Now, go to the library and find a *good*
book on learning to *use* (not install; not admin) Unix. I heartily
recommend Unix Unbound by Harley Hahn, but it's likely long out of print.
Other books by the same author are also likely as good, though. Read it.
Maybe even read another. Try some of the examples provided.
You can still revert to using the simpler editors for day-to-day tasks
if you prefer, but if you want to be able to walk up to any Unix/Linux
system, perhaps running from an installation CD, and save the day because
the "clueless user" botched it, you pretty much *need* to be able to
perform at least basic editing with vi.
> ... Vi does NOT behave like a text editor. It behaves like Vi. There
> is a significant difference there, one that puts Vi outside
> consideration when there are way faster ways of resolving a simple
> text editing problem.
Yes there are, but notice that no one is suggesting you should learn to
use "ed".
Imagine a scenario that's similar to the one you proposed, but the system
needing repair does not recognize its console. It'll talk to you line by
line, but no way would anything requiring a screenful to display work.
That happened to me many years ago. I had two choices, really: start
over (which wasn't a realistic option at the time), or figure out on
the spot how to get "ed" to edit the file I needed. Note that "ed"
ultimately works with the same sorts of commands as vi uses, but is kind
of like having a vi perpetually in command-mode, without the benefit of
screenful display. Luckily for me, I'd gained some familiarity with vi
by that time. ...
--
----------------------------------------------------------------------
Sylvain Robitaille s...@encs.concordia.ca
Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------