Re: Here document and stdin?

2010-08-15 Thread Mike Frysinger
On Sun, Aug 15, 2010 at 8:47 PM, Peng Yu wrote: > cat file.txt | sqlite3 main.db <

Here document and stdin?

2010-08-15 Thread Peng Yu
Here, I have the following working sql script, which takes /dev/stdin as input. Then I want to convert it to a here document. But it doesn't work, as shown below. I think that this may not be a sqlite3 problem. Rather, it may be because I don't use here document and pipe correctly. Could any bash

Re: \c escape within $'...' can produce mangled UTF-8

2010-08-15 Thread Mike Frysinger
On Sun, Aug 15, 2010 at 4:09 PM, Dmitry Groshev wrote: > On 15/08/2010, Mike Frysinger wrote: >> you might want to try being less abrasive if you expect people to help you > > It will be a cold day in the netherworld when I'll need help fixing a > bug. So I can afford to be as "abrasive" as I wish.

Re: Wrong prompt and incorrect parsing if completion is used

2010-08-15 Thread Egmont Koblinger
Hi Chet, Thanks for fixing it! Sorry I didn't provide the output you requested, I was on vacation for a week, and now it seems you no longer need it :) egmont On Aug 15, 2010 6:22 PM, "Chet Ramey" wrote: > On 8/9/10 12:02 PM, Egmont Koblinger wrote: > >> Start over, type the following (replace

Re: \c escape within $'...' can produce mangled UTF-8

2010-08-15 Thread Dmitry Groshev
On 15/08/2010, Mike Frysinger wrote: > you might want to try being less abrasive if you expect people to help you It will be a cold day in the netherworld when I'll need help fixing a bug. So I can afford to be as "abrasive" as I wish. Reporting this bug had turned out to be quite an useless wast

Re: \c escape within $'...' can produce mangled UTF-8

2010-08-15 Thread Mike Frysinger
On Sun, Aug 15, 2010 at 6:02 AM, Dmitry Groshev wrote: > On 15/08/2010, Dennis Williamson wrote: >> It only consumes two bytes on my system (or one if it's followed by >> another escape or a closing quote). > > You are wrong. you might want to try being less abrasive if you expect people to help y

Re: Wrong prompt and incorrect parsing if completion is used

2010-08-15 Thread Chet Ramey
On 8/9/10 12:02 PM, Egmont Koblinger wrote: > Start over, type the following (replace TAB by pressing the TAB key): > ps1$ cd /biTAB` > The auto-completed command looks exactly as the manually typed one, hence > the expected behavior is the same. However, press Enter, and the primary > prompt get

Re: \c escape within $'...' can produce mangled UTF-8

2010-08-15 Thread Andreas Schwab
Dmitry Groshev writes: > Everything between 0x80 and 0xFF is part of (possibly invalid) > multibyte sequence in UTF-8. Who says that the string is UTF-8 encoded? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now

Re: \c escape within $'...' can produce mangled UTF-8

2010-08-15 Thread Dmitry Groshev
On 15/08/2010, Dennis Williamson wrote: > It only consumes two bytes on my system (or one if it's followed by > another escape or a closing quote). You are wrong. Try "echo $'\x{123456}AB'" and look at the result. Or read the source code: lib/sh/strtans.c > "Backslash-escaped characters" refers

Re: \c escape within $'...' can produce mangled UTF-8

2010-08-15 Thread Andreas Schwab
Dennis Williamson writes: > It's the responsibility of your code to put an ASCII character after > the \c. There's no way for Bash to guess that the 0xD0 is part of a > Unicode character or the byte that it is. It can, by using mbrlen. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key

Re: \c escape within $'...' can produce mangled UTF-8

2010-08-15 Thread Dennis Williamson
>This leap of illogic is beyond my ken. As a counterexample, "\x{...}" >escape can consume an unlimited number of bytes while producing a >single byte. It only consumes two bytes on my system (or one if it's followed by another escape or a closing quote). > Because the documentation says "backsla