> Note: I only wanted to point out something that bothered me. I'm not
> using mg(1) these days and I don't plan to spend time on this issue.
That’s pretty much the modern internet, summarized in two sentences
Regardless of the decision on which way the behavior should go, it is a
documentation bug either way. (E.g. beginning-of-buffer is missed
entirely). Probably my fault (from a lng time ago.)
On Wed, May 22, 2019 at 8:53 AM Leonid Bobrov wrote:
> On Wed, May 22, 2019 at 01:36:41PM +0200, Jerem
Oh goodness. My recollection is that 1 byte per character is assumed all
over the place. This is going to take a *while* to test properly.
Maybe this is a good time for me to start looking at mg again...
On Thursday, 21 January 2016, Mark Lumsden wrote:
> I am busy for the next month or so, but
It should be noted, You can do that (without a code change) with an
appropriate chunk of code in your ~/.mg file.
(at least, that's how I have always done it)
On Tuesday, October 7, 2014, Stuart Cassoff wrote:
> On 08/13/14 18:51, Brian Callahan wrote:
> > Hi tech --
> >
> > Diff below adds the
I think the massive mg user base can handle a single flavor. :)
On Thu, Jun 28, 2012 at 11:20 AM, Eichert, Diana wrote:
> On Thu, Jun 28, 2012 at 08:35:18AM -0400, Kjell Wooding wrote:
>
> > 2. I should point out that all of mg (other than theo.c) is currently
> > PUBLIC DOMA
Thoughts, since we have been down this road before.
1. You can remap keys, in your ~/.mg file
2. I should point out that all of mg (other than theo.c) is currently
PUBLIC DOMAIN, not merely BSD, so this change is significant, license-wise.
Please be pedantic about including licenses.
3. Why sche
Regardless, I stand by my original comment. :)
On Thursday, March 29, 2012, Jason McIntyre wrote:
> On Thu, Mar 29, 2012 at 12:00:56AM -0400, Kjell Wooding wrote:
> > There's nothing *technically* wrong with "irrespective," but it is a tad
> > awkward
There's nothing *technically* wrong with "irrespective," but it is a tad
awkward when compared with "regardless."
"irregardless" is a hangable offense.
On Wed, Mar 28, 2012 at 1:40 AM, Jason McIntyre wrote:
> On Tue, Mar 27, 2012 at 10:46:46PM -0400, K
s/irrespective/regardless/
On Tue, Mar 27, 2012 at 12:57 PM, Sunil Nimmagadda <
su...@sunilnimmagadda.com> wrote:
> This version implements some off-list review comments...
>
> 1. Discard explicit checking whether command exists and it's
> permissions since shell already does and reports error.
>
I would think that automatically reading any file in pwd named "tags," and
trying to parse it as a tags file *by default* whenever mg is started is a
bad choice.
> Looks quite fine, but I noticed there are no NULL checks for the
> newly allocated strings. Aborting a command gracefully might be
> better than crashing, should anyone ever be unfortunate enough
> to hit this.
Absolutely true. And in thinking about adding such checks, I realize
they just ugify
And this is the other frequently encountered issue for people
trying to port our mg changes elsewhere. dirname and basename
are usually stupid on other platforms, modifying their input strings,
and other such silliness.
This fixes this issue by wrapping everything in allocating
routines. It requir
Over the years, I have gotten numerous mails from people having difficulty
compiling mg on other platforms. Most of these mails fall into one of two
categories:
* struct dirent problems,
* basename, dirname problems
This diff addresses the former. The essential problem is that many platforms
d
Yeah, nice catch on the twiddle bug. This looks pretty good. Anyone else try
it?
-kj
On Mon, Jan 17, 2011 at 10:10 AM, Henri Kemppainen wrote:
> > Looks pretty good. I might add an undo boundary
> > around the whole thing (I note emacs doesn't do this
> > properly, at least on the version I hav
> I'm afraid simply adding the the undo boundary around newline()
> will break yank(), which sets its own boundary and calls newline()
> among other changes. If we want this undo stuff, then we probably
> should add checks such that none of these functions set boundaries
> if they were disabled (b
augbname does the basename itself. No point calling it twice.
Index: file.c
===
RCS file: /cvs/src/usr.bin/mg/file.c,v
retrieving revision 1.72
diff -u -r1.72 file.c
--- file.c 26 Jun 2010 16:18:44 - 1.72
+++ file.c
Well, this seems to be an obvious error on my part (since llength
returns an int). Found while doing a portability sweep.
ok?
Index: line.c
===
RCS file: /cvs/src/usr.bin/mg/line.c,v
retrieving revision 1.49
diff -u -r1.49 line.c
--
-kj
On Mon, Jan 17, 2011 at 9:52 AM, Han Boetes wrote:
> Kjell Wooding wrote:
> > I might add an undo boundary around the whole thing (I note
> > emacs doesn't do this properly, at least on the version I have
> > here)...
>
> Undoing join-line works fine with the e
Looks pretty good. I might add an undo boundary
around the whole thing (I note emacs doesn't do this
properly, at least on the version I have here)...
like so:
Index: def.h
===
RCS file: /cvs/src/usr.bin/mg/def.h,v
retrieving revisio
> Note that this assumes that there is no backdoor in random(6) (or
> arc4random_uniform, which it calls) designed to prevent the source file
> with the backdoor from being selected with the above command.
>
>
That's true. I would submit a patch, but it would require every developer to
carry around
> > There are arc4random_buf () calls in the kernel. Those can use the
> > arc4random_buf_large() mechanism, can thy not? Or are the requests
> typically
> > too small?
>
> arc4random_buf_large() is not exported as an API; this is intentional.
>
> If you do arc4random_buf_large() for a small buffe
Hi Damien.
On Tue, Dec 28, 2010 at 1:45 PM, Damien Miller wrote:
> On Tue, 28 Dec 2010, Kjell Wooding wrote:
>
> > How would a preimage attack matter in this case?
>
> It gives you knowledge of the collection pool, which is what the very
> thing the design is supposed to av
uests, and so on.
Anyway, I'm muttering aloud now. In the meantime, is there any reason to
keep the fold?
On Tue, Dec 28, 2010 at 1:48 AM, Damien Miller wrote:
> On Mon, 27 Dec 2010, Kjell Wooding wrote:
>
> > The OpenBSD random number subsystem uses an in-kernel entropy poo
Probably my (pasting) bad. This isn't my favourite mailer. patch -l will fix
that though...
On Mon, Dec 27, 2010 at 7:33 PM, Nima Hoda wrote:
> On Mon, Dec 27, 2010 at 03:01:57PM -0700, Kjell Wooding wrote:
> > Looks good. Here is a slight cleanup. Essentially, fix alphabetica
The OpenBSD random number subsystem uses an in-kernel entropy pool. This
data isn't used directly. When entropy is requested, the contents of the
pool are hashed with MD5, and the massaged output used to seed an RC4 PRNG.
In looking at the code, however, I notice we actually fold the MD5 output in
Looks good. Here is a slight cleanup. Essentially, fix alphabetical
ordering, change function name :
Index: def.h
===
RCS file: /cvs/src/usr.bin/mg/def.h,v
retrieving revision 1.113
diff -u -u -r1.113 def.h
--- def.h30 Jun 2010 19
On Wed, Dec 22, 2010 at 12:24 PM, Marsh Ray wrote:
> On 12/22/2010 11:44 AM, Kjell Wooding wrote:
>
>> Can you please stop wasting time asking questions before you bother to
>> read
>> about what you are asking?
>>
>
> Consider the possibility that I have,
Can you please stop wasting time asking questions before you bother to read
about what you are asking?
On Wed, Dec 22, 2010 at 10:00 AM, Marsh Ray wrote:
> How is this different, except for perhaps the intermediate arc4 cipher.
> What does that add, other than crappiness? (RC4 is known to be
> di
> It *seems harder* (but I'm not an expert on this kind of thing!) to
> predict the first couple of rounds if is hashed (which
> means that you have to re-do the complete calculation for each possible
> , which may not necessarily be the case above), and if
> this hashing is used to distribute the
>"MD5(time), MD5(time + 1ns), MD5(time + 2ns) etc into the buffer. This
does not increase entropy, but having more-or-less uncorrelated data
in the entire buffer should make attacks more difficult."
No. Unless you know something I don't, This is voodoo. To do it once might
add something, but to
the first non-whitespace character of the line.
> >
> > That's not the way emacs behaves and mg is supposed to be
> > finger-compatible with emacs.
> >
> > --
> > Christian "naddy" Weisgerber na...@mips.inka.de
This diff fixes some issues around sasyncd's handling
of the carpdemote flag, fixing some signal handling, cleanup,
and logging issues.
Here's the problem I am seeing. Some background:
# ifconfig -g carp
carp: carp demote count 0
This is the normal case. If I poke the demote counter (essenti
> Very good suggestion, indeed.
>
> Especially, if someone has a 'dangerous' file, a PHP Shell for instance,
> (a perfect example:
> http://mgeisler.net/downloads/phpshell/phpshell-1.7.tar.gz)
> inside such a directory. (Or even maybe a simple file uploader, that will
> help the attacker to uplo
> Frankly, having scheme in without any support for REPL in mg is not
> that awesome. What makes elisp so handy is an ability to see what
> happens in realtime while programming (the usual Lisp/REPL development
> way).
pthth. I don't care if elisp is handy. That's not the point. The point is,
wou
Not to mention, if done properly, we can actually remove code from mg,
replacing it with scripted "extensions"
I'm not deliberately ignoring this. I'm just innundated with thesis
work for the next few weeks...
-kj
> > This is incorrect. This file is not for documentation, it is for
> > configuration. If the user adds a new option to the file, it does not
> > suddenly become commonly used.
>
> Ok. What is intended in the proposed changes is that the list be
> identified as intentionally a subset of those
36 matches
Mail list logo
