> Primarily DVI, but also observed with VGA.
> LCD screens, in all cases.
can you look at pixels through a magnifying glass and see if an image
pixel affects more than one physical one? may it happen there's a
resolution mismatch?
VGAs can have artifacts which is very hard to get fixed: it is ver
Primarily DVI, but also observed with VGA.
LCD screens, in all cases.
-sl
2012/6/12 :
>>> In native, I no longer benefit from X11's rendering. Here, blurry
>>> fonts look blurry.
Sorry, is it DVI or VGA-connected?
Another pretty good mini pc IMHO is the amazon kindle touch. Leetspete from
#inferno helped me get inferno on it (and the graphics will probably work once
I get twm on it too) it's supper cheap (the ad supported one costs 75 bucks!)
and has a ridicules battery life. The firmware is also open sou
On Thu, Jun 14, 2012 at 10:49:51AM -0400, erik quanstrom wrote:
> >
> > > cpu% echo hola | grep ''
> > > grep: empty pattern
> >
> > From the POSIX description, an empty pattern is not allowed. '*' is not
> > an empty pattern.
>
> i'm sorry this just isn't correct. see the man page.
>
> plan
On Thu, Jun 14, 2012 at 4:46 PM, erik quanstrom
wrote:
>> cpu% echo hola | grep '*'
>> grep: *: syntax error
>> cpu% echo hola | grep ''
>> grep: empty pattern
>>
>>
>> grep '*' and grep '' should still be the same, shouldn't they?
>
> yes, but does it matter?
Probably not.
G.
On Thu Jun 14 10:37:21 EDT 2012, tlaro...@polynum.com wrote:
> On Thu, Jun 14, 2012 at 04:13:12PM +0200, Gorka Guardiola wrote:
> > Also this:
> >
> > cpu% echo hola | grep '*'
> > grep: *: syntax error
>
> The plan9 regexp are mainly Extended Regular Expression. If the POSIX
> description is ta
> cpu% echo hola | grep '*'
> grep: *: syntax error
> cpu% echo hola | grep ''
> grep: empty pattern
>
>
> grep '*' and grep '' should still be the same, shouldn't they?
yes, but does it matter? you correctly get an error either way.
- erik
On Thu, Jun 14, 2012 at 04:13:12PM +0200, Gorka Guardiola wrote:
> Also this:
>
> cpu% echo hola | grep '*'
> grep: *: syntax error
The plan9 regexp are mainly Extended Regular Expression. If the POSIX
description is taken, a leading '*' is a syntax error. I guess that the
leading '*' followed b
On Thu, Jun 14, 2012 at 4:00 PM, wrote:
> On Thu, Jun 14, 2012 at 09:44:25AM -0400, erik quanstrom wrote:
>> > > nope, that's not right. * starting a pattern escapes the whole string.
>> > > this is unique to grep.
>
> I guess this is surprising because with a POSIX grep(1), if I read the
> desc
On Thu, Jun 14, 2012 at 09:44:25AM -0400, erik quanstrom wrote:
> > > nope, that's not right. * starting a pattern escapes the whole string.
> > > this is unique to grep.
I guess this is surprising because with a POSIX grep(1), if I read the
description correctly:
1) If the * is the very charact
>> > nope, that's not right. * starting a pattern escapes the whole string.
>> > this is unique to grep.
>> >
>>
>> Argh, yes, it has a special meaning. I have somehow managed to miss
>> this for all this time.
>
> it's easy to miss, but critical especially since we have other implementations
>
> > nope, that's not right. * starting a pattern escapes the whole string.
> > this is unique to grep.
> >
>
> Argh, yes, it has a special meaning. I have somehow managed to miss
> this for all this time.
it's easy to miss, but critical especially since we have other implementations
that don't d
On Thu, Jun 14, 2012 at 3:33 PM, erik quanstrom
wrote:
> On Thu Jun 14 04:29:51 EDT 2012, pau...@gmail.com wrote:
>> While playing with grep, I was suprised by grep '*\.c' not giving
>> an error (* is missing an operand). Arguably * applied to empty
>
> nope, that's not right. * starting a patter
On Thu Jun 14 04:29:51 EDT 2012, pau...@gmail.com wrote:
> While playing with grep, I was suprised by grep '*\.c' not giving
> an error (* is missing an operand). Arguably * applied to empty
nope, that's not right. * starting a pattern escapes the whole string.
this is unique to grep.
from grep(
> This combined with the fact that multiple
> "stars" are coalesced causes the weirdness
> you're seeing.
there is no case of multiple '*'s in the patterns peter gave.
there is a case of patterns beginning with '*' which treats the
rest of the pattern as a literal, but that's different.
- erik
> % echo foo.c | 9 grep '*\.c'
correct. match \.c as a literal string. there is no match.
> % echo foo.c | 9 grep '*.c'
> foo.c
correct. match .c as a littal string. there is a match.
> % echo fooxc | 9 grep '*.c'
> %
> % echo fooxc | 9 grep '.*.c'
> fooxc
correct. match 0-n any character
It happened again. and I've just realized it's simply what you had
warned about: since it was an --amend and I didn't change anything in
the message there was no change to the ls -l output, hence E did
nothing when I Put.
On Fri, Apr 27, 2012 at 12:20 AM, Mathieu Lonjaret
wrote:
> I've just retri
2012/6/12 Wes Kussmaul :
> When you send an xkcd link to a large list, you make a dent in the
> world's productivity. You can't look at just one.
You have no idea how much right you are!
On Thu, Jun 14, 2012 at 11:32 AM, Peter A. Cejchan wrote:
> This is from manpage, but I not sure what _exactly_ it means, and whether it
> applies to your problem:
> Care should be taken when using the shell metacharacters
> $*[^|()=\ and newline in pattern; it is safest to enc
% sed -n 20,32p /sys/src/cmd/grep/grep.y
prog: /* empty */
{
yyerror("empty pattern");
}
| expr newlines
{
$$.beg = ral(Tend);
$$.end = $$.beg;
$$ = re2cat(re2star(re2or(re2char(0x00, '\n'-1),
re2char('
This is from manpage, but I not sure what _exactly_ it means, and whether
it applies to your problem:
Care should be taken when using the shell metacharacters
$*[^|()=\ and newline in pattern; it is safest to enclose
the entire expression in single quotes '...'. An ex
While playing with grep, I was suprised by grep '*\.c' not giving
an error (* is missing an operand). Arguably * applied to empty
can match empty, but surprisingly enough, Acme's edit behaves
differently. And even grep is not consistent (grep '*' is different than
grep '' whereas both should be an
23 matches
Mail list logo
