Created on 2008-01-21.18:01:07 by z3ttacht, last changed 2008-02-11.17:15:39 by mika.
msg1170 (view) |
Author: mika |
Date: 2008-02-11.17:15:39 |
|
We believe that your issue has been closed by the upload of
Version 0.3.48 of grml-etc-core from Michael Prokop <mika@grml.org>.
The explanation is attached below
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Mon, 11 Feb 2008 17:58:42 +0100
Source: grml-etc-core
Binary: grml-etc-core
Architecture: source all
Version: 0.3.48
Distribution: unstable
Urgency: low
Maintainer: Michael Prokop <mika@grml.org>
Changed-By: Michael Prokop <mika@grml.org>
Description:
grml-etc-core - core ecetera files for the grml system
Changes:
grml-etc-core (0.3.48) unstable; urgency=low
.
[ Alexander Steinböck ]
* zshrc: use $PAGER in dchange(), uchange() and dnews() [Closes: issue386]
* zshrc: adding whatwhen() for history queries [Closes: issue380]
.
[ Frank Terbeck ]
* zshrc: add a check for ZSH_VERSION >= 3.1.7 [Closes: issue389]
.
[ Michael Prokop ]
* zshrc: enable 'setopt longlistjobs' by default
* zshrc: re-enable use of 'sudo su' instead of 'sudo -s' for alias su,
otherwise it breaks "su - $USER". Thanks for bringing this up,
Martin Yazdzik!
Files:
6be0fd2d17c9ead9563840024ff703b1 596 grml optional grml-etc-core_0.3.48.dsc
66e70ab672205c0ed5ea4cb9ac81d42d 93953 grml optional grml-etc-core_0.3.48.tar.gz
875ecf9abd3830a82454c72a11a55861 96316 grml optional grml-etc-core_0.3.48_all.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHsH+R2N9T+zficugRApgvAJ9bntatOGTPEda4KrSnQM9Us0cYnQCePuMb
zrMV985Ogx3IIlAUcg2eGy8=
=qsrF
-----END PGP SIGNATURE-----
|
msg1132 (view) |
Author: z3ttacht |
Date: 2008-01-31.07:41:35 |
|
> Frank Terbeck <ft@bewatermyfriend.org> added the comment:
> > > Also, if you want this function to be included in the
> > > grml-zsh-refcard, add an appropriate tag in front of it.
> > I was assuming, another instance - as in you or mika -
> > decides what's mentioned in the refcard.
> I think we should add everything to the refcard.
> *As* *long* *as* it does not blow up beyond the size of two a4 pages.
Ok, good deal. Should be fixed.
|
msg1124 (view) |
Author: ft1 |
Date: 2008-01-30.09:52:41 |
|
Alexander Steinböck <bts@bts.grml.org>:
> Alexander Steinböck <z3ttacht@grml.org> added the comment:
> * Frank Terbeck <bts@bts.grml.org> [2008-01-22 12:43]:
> > > Alexander Steinböck <bts@bts.grml.org>:
> > Also, if you want this function to be included in the
> > grml-zsh-refcard, add an appropriate tag in front of it.
>
> Do I? (o; I was assuming, another instance - as in you or mika -
> decides what's mentioned in the refcard. Is that function important
> enough for it?
> But, I'll be happy to do that.
Well.
I think we should add everything to the refcard.
*As* *long* *as* it does not blow up beyond the size of two a4 pages.
But since we are able to generate the refcard automatically,
everything should be added (and I mean everything, also the functions,
that are currently not on it - minus the utility functions only used
by the zshrc itself); And when it reaches beyond two a4 pages, we can
revise which functions are not important enough, so we can leave them
out.
> > And last but not least: Do we want this function in etc/zsh/zshrc or
> > in etc/skel/.zshrc?
>
> As mentioned in the diff, I was going for etc/skel/.zshrc. So, it
> would be just available for normal users. Don't know, does it give
> advantages to a root account as well?
No, fine. I would place it in .zshrc, too.
Regards, Frank
--
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
-- RFC 1925
|
msg1108 (view) |
Author: z3ttacht |
Date: 2008-01-27.15:51:15 |
|
* Frank Terbeck <bts@bts.grml.org> [2008-01-22 12:43]:
> > Alexander Steinböck <bts@bts.grml.org>:
> Also, if you want this function to be included in the
> grml-zsh-refcard, add an appropriate tag in front of it.
Do I? (o; I was assuming, another instance - as in you or mika -
decides what's mentioned in the refcard. Is that function important
enough for it?
But, I'll be happy to do that.
> And last but not least: Do we want this function in etc/zsh/zshrc or
> in etc/skel/.zshrc?
As mentioned in the diff, I was going for etc/skel/.zshrc. So, it
would be just available for normal users. Don't know, does it give
advantages to a root account as well?
Kind regards,
z3ttacht
|
msg1107 (view) |
Author: z3ttacht |
Date: 2008-01-27.15:50:03 |
|
* Frank Terbeck <bts@bts.grml.org> [2008-01-22 12:48]:
> > [...]
> > Because bash seems to have a command for this. But I don't remember it.
> Bash has this? Never heard of that. Nor would I care.
,----[ IRC log #zsh - Fri Sep 21 2007 ]-
| 15:39 [dnme ]: is there something to format the history time in .history for zsh ?
| 15:39 [dnme ]: I'm switching from bash3
| 15:39 [dnme ]: and there I had somethinglike HISTTIMEFORMAT
| 15:40 [ ft ]: what did that do?
| 15:40 [dnme ]: that showed me the time of any commands in the format I chose
| 15:40 [dnme ]: for example:
| 15:40 [dnme ]: 4369 [Thu 2007/09/20 16:53:06] vim /etc/hosts
| 15:40 [dnme ]: 4370 [Thu 2007/09/20 16:55:04] cat /etc/host
| 15:40 [dnme ]: 4371 [Thu 2007/09/20 16:55:05] cat /etc/hosts
`----
> I'm not against this function at all, I'd just never use it.
Lucky me. (o;
> This obviously requires extended_history, which grml enables by
> default, so that should not be an issue.
OK. I took it for granted as well. (o;
> > einfo ${usage} ; /bin/false ; eend $?
> Personally, I dislike using these e*() function for anything else but
> system scripts. For shell functions (which basically work a lot like
> usual programs/commands) I'd prefer plain output a lot.
OK. Fine by me. I was just geared to grml's policy[1]. And
unfortunately didn't differ between scripts and functions regarding to
it.
> > fc -lE -m "*[${(L)1[1]}${(U)1[1]}]${1[2,-1]}*" ${2:-\-100} $3
> Would you mind explaining this one a bit?
> I'm not exactly familiar with the 'fc' builtin.
-l list results on stout rather than invoking $EDITOR.
-i Print dates as in YYYY-MM-DD. (-i is now used instead of -E, which is dd.mm.yyy)
-m Search for a - quoted - pattern within the history.
It's commented in the function itself as well now.
> Also, I would assign $1 etc. to named variables, which would increase
> readability.
Usually I try to avoid setting two much parameter for a simple
function. But it's fine by me to do so of course.
And _yes_, it does improve readability. (o;
---------- Footnotes ----------
[1] http://grml.org/policy -- 5.3.1. /etc/grml/lsb-functions
|
msg1085 (view) |
Author: ft1 |
Date: 2008-01-22.11:24:33 |
|
[..whatwhen()..]
Also, if you want this function to be included in the
grml-zsh-refcard, add an appropriate tag in front of it.
eg:
[snip]
#f1# show entries in zsh history
whatwhen() {
[snap]
And last but not least: Do we want this function in etc/zsh/zshrc or
in etc/skel/.zshrc? The former would make it available for all users
including root, the latter only for normal users. See the refcard for
where it would fit.
If you decide to put it into the skel file, use '#f2#' instead of
'#f1#' as the tag.
These tags are documented on top of etc/zsh/zshrc and on top of the
genrefcard.pl script.
Regards, Frank
|
msg1084 (view) |
Author: ft1 |
Date: 2008-01-22.10:55:10 |
|
[...]
> Why?
> Because there have been several questions on #zsh{,.de} on how to get
> events from the history with the date included a command was invoked.
> Because bash seems to have a command for this. But I don't remember it.
Bash has this? Never heard of that. Nor would I care.
I'm not against this function at all, I'd just never use it.
This obviously requires extended_history, which grml enables by
default, so that should not be an issue.
[...]
> + whatwhen() {
[...]
> + einfo ${usage} ; /bin/false ; eend $?
Personally, I dislike using these e*() function for anything else but
system scripts. For shell functions (which basically work a lot like
usual programs/commands) I'd prefer plain output a lot.
[...]
> + fc -lE -m "*[${(L)1[1]}${(U)1[1]}]${1[2,-1]}*" ${2:-\-100} $3
[...]
Would you mind explaining this one a bit?
I'm not exactly familiar with the 'fc' builtin.
Also, I would assign $1 etc. to named variables, which would increase
readability.
Regards, Frank
|
msg1083 (view) |
Author: z3ttacht |
Date: 2008-01-21.18:13:20 |
|
Why?
Because there have been several questions on #zsh{,.de} on how to get
events from the history with the date included a command was invoked.
Because bash seems to have a command for this. But I don't remember
it.
|
msg1082 (view) |
Author: z3ttacht |
Date: 2008-01-21.18:01:06 |
|
whatwhen() -- Get what you did when from the history.
e.g. % whatwhen grml
6682 21.1.2008 09:59 vim etc/grml/screenrc
6683 21.1.2008 10:00 screen -c etc/grml/screenrc
|
|
Date |
User |
Action |
Args |
2008-02-11 17:15:39 | mika | set | status: chatting -> resolved nosy:
mika, ft, z3ttacht messages:
+ msg1170 |
2008-01-31 07:41:35 | z3ttacht | set | files:
+ grml-etc-core-zshrc-whatwhen_improved_refcardtag.patch nosy:
mika, ft, z3ttacht messages:
+ msg1132 |
2008-01-30 09:52:42 | ft1 | set | nosy:
mika, ft, z3ttacht messages:
+ msg1124 |
2008-01-27 15:51:15 | z3ttacht | set | nosy:
mika, ft, z3ttacht messages:
+ msg1108 |
2008-01-27 15:50:04 | z3ttacht | set | files:
+ grml-etc-core-zshrc-whatwhen_improved.patch nosy:
mika, ft, z3ttacht messages:
+ msg1107 |
2008-01-23 17:07:05 | mika | set | nosy:
+ mika |
2008-01-22 11:24:34 | ft1 | set | nosy:
ft, z3ttacht messages:
+ msg1085 |
2008-01-22 10:55:11 | ft1 | set | nosy:
ft, z3ttacht messages:
+ msg1084 |
2008-01-21 18:13:20 | z3ttacht | set | status: unread -> chatting nosy:
ft, z3ttacht messages:
+ msg1083 |
2008-01-21 18:01:07 | z3ttacht | create | |
|