This wchar in Windows is UTF-16.
https://msdn.microsoft.com/en-us/library/windows/desktop/ff381407(v=vs.85).aspx
Manfred
> Am 02.03.2017 um 19:51 schrieb Greg Hellings :
>
> My only thought is that Windows doesn't use UTF-8 internally (it uses
> UTF-16), while Sword
On 03/02/2017 02:14 PM, Greg Hellings wrote:
> I also get no results.
On the other hand...
$ mod2imp KJV | grep -B1 -i abed.nego | fgrep '$$'
$$$Daniel 1:7
$$$Daniel 2:49
$$$Daniel 3:12
$$$Daniel 3:13
$$$Daniel 3:14
$$$Daniel 3:16
$$$Daniel 3:19
$$$Daniel 3:20
$$$Daniel 3:22
$$$Daniel 3:23
Here they are - ten pages without a category, two of which we can ignore.
https://crosswire.org/wiki/Special:UncategorizedPages
David
--
View this message in context:
http://sword-dev.350566.n4.nabble.com/Uncategorised-pages-in-our-developers-wiki-tp4656885.html
Sent from the SWORD Dev
Typo was only in the message, sorry!
The actual test in Windows shell with the -k there didn't give any matches.
David
--
View this message in context:
http://sword-dev.350566.n4.nabble.com/diatheke-search-type-regex-and-the-dot-tp4656879p4656884.html
Sent from the SWORD Dev mailing list
Nearly eight years ago, this wiki page was made by Peter:
https://crosswire.org/wiki/Complete_Lexicon_Functionality
Looks like either everyone lost interest, or nobody else took any
interest
Worth revisiting?
David
--
View this message in context:
$ diatheke -b KJV -s regex -k Abed.nego
Verses containing "Abed.nego"-- none (KJV)
Once I correct the command to include the -k parameter, I also get no
results.
--Greg
On Thu, Mar 2, 2017 at 12:58 PM, David Haslam wrote:
> I was under the impression that the
I suspect this may be a further symptom of what Greg suggested as the
explanation in my other thread.
i.e. That SWORD expects to search in UTF-8 encoded text, whereas Windows
uses UTF-16 internally.
Still can't quite make out why the dot isn't treated how regular expressions
use it.
David
--
Thanks, Greg.
That's the best explanation that I've seen so far.
David
--
View this message in context:
http://sword-dev.350566.n4.nabble.com/In-Windows-command-shell-diatheke-search-is-restricted-to-ASCII-for-the-query-key-tp4656866p4656880.html
Sent from the SWORD Dev mailing list archive
I was under the impression that the metacharacter *dot* in a regex means "any
single character".
It would seem that for diatheke with *-s regex* this is not the case at all.
Example:
diatheke -b KJV -s regex Abed.nego
In Windows command shell, that command line does not find the 15 instances
My only thought is that Windows doesn't use UTF-8 internally (it uses
UTF-16), while Sword assumes and demands UTF-8. Perhaps diatheke just
blindly consumes its input as UTF-8, and goes along its merry way?
--Greg
On Thu, Mar 2, 2017 at 11:48 AM, David Haslam wrote:
>
On Thu, Mar 2, 2017 at 11:50 AM, Karl Kleinpaste
wrote:
> On 03/02/2017 12:17 PM, David Haslam wrote:
>
> I am assuming that when Karl bundles these with Xiphos, he just uses what's
> available and most recent in our SVN.
>
> I don't build/bundle them. They're whatever Greg
Exactly how they get compiled is beyond my pay grade.
Even the jargon in your reply is outside my ken. ;>)
David
--
View this message in context:
http://sword-dev.350566.n4.nabble.com/In-Windows-command-shell-diatheke-search-is-restricted-to-ASCII-for-the-query-key-tp4656866p4656877.html
Greg,
It was worth a test inside cygwin and the result was also a fail:
$ xiphos/diatheke -b KJV -s regex -k Æneas
Verses containing "ãneas"-- none (KJV)
I tried it with this too, and that fare no better:
$ utils/diatheke -b KJV -s phrase -k Æneas
Verses containing "ãneas"-- none (KJV)
That's
On 03/02/2017 12:17 PM, David Haslam wrote:
> I am assuming that when Karl bundles these with Xiphos, he just uses what's
> available and most recent in our SVN.
I don't build/bundle them. They're whatever Greg built into the MinGW
Sword RPM. The Windows build script just includes them in the
The only reason I'm using the Sword utilities bundled with Xiphos is because
they happen to be a more recent version than what I can find in the
ftpmirror on our server.
The former has diatheke version 4.7 and the latter diatheke version 4.6
I am assuming that when Karl bundles these with
Thanks Karl.
I suppose Linux also succeeds when the *en dash* is properly used with any
of the "hyphenated" names such as:
Abel–beth–maachah
Under Windows CMD, diatheke changes these to U+00FB LATIN SMALL LETTER U
WITH CIRCUMFLEX.
S:\>xiphos\diatheke -b KJV -s phrase -k Abel–beth–maachah
On Thu, Mar 2, 2017 at 10:27 AM, David Haslam wrote:
> Hi Greg,
>
> Windows 7 x64 using ordinary cmd.exe as the command shell.
>
> Do you think I'd get better results if I called diatheke.exe from inside a
> cygwin shell ?
>
I think that I don't like to think about
On Thu, Mar 2, 2017 at 10:29 AM, Karl Kleinpaste
wrote:
> On 03/02/2017 11:14 AM, David Haslam wrote:
>
> Such a diatheke command works OK in Linux, or so I'm told.
>
> $ diatheke -b KJV -s regex -k Æneas
> Entries containing "Æneas"-- none (KJV)
> $ diatheke -b KJV -s
Hi Greg,
Windows 7 x64 using ordinary cmd.exe as the command shell.
Do you think I'd get better results if I called diatheke.exe from inside a
cygwin shell ?
btw. I've never used Windows PowerShell.
I even had to look it up in https://en.wikipedia.org/wiki/PowerShell
How come this only came to
On 03/02/2017 11:14 AM, David Haslam wrote:
> Such a diatheke command works OK in Linux, or so I'm told.
$ diatheke -b KJV -s regex -k Æneas
Entries containing "Æneas"-- none (KJV)
$ diatheke -b KJV -s lucene -k Æneas
Entries containing "Æneas"-- Acts 9:34Acts 9:33 ; -- 2 matches total (KJV)
$
Don't use Windows?
But in all seriousness, is this in CMD or PowerShell? What version of
Windows is this? You very possibly could be running into a limitation of
the operating system.
--Greg
On Thu, Mar 2, 2017 at 10:14 AM, David Haslam wrote:
> This simply doesn't work
This simply doesn't work inside the Windows command line shell.
S:\>xiphos\diatheke -b KJV -s regex -k Æneas
Verses containing "ãneas"-- none (KJV)
It changes the non-ASCII characters to something else entirely!
Such a diatheke command works OK in Linux, or so I'm told.
Is there a solution?
> Gesendet: Donnerstag, 02. März 2017 um 08:47 Uhr
> Von: "David Haslam"
> AFAIK, diatheke itself cannot generate a lucene index for a module.
Correct. You can use mkfastmod as a commandline tool or indeed use xiphos'
indeces.
Peter
AFAIK, diatheke itself cannot generate a lucene index for a module.
You can specify the search type as *-s lucene* to ensure that it will make
use of any existing index that the user may have already generated from
another front-end such as Xiphos.
Is my understanding correct?
btw. For modules
24 matches
Mail list logo