Hi John-
Beg pardon, I should have mentioned earlier that since docsplit plants a
.txt file in the target pdf's
directory on its own, with no other output, I had gone the route you
suggested, but to no avail, i.e.,

"docsplit text --no-clean -l path" run-process drop

In  the terminal,  cd /path/to/1_long_gu ; docsplit text --no-clean -l
chi_sim long_gu001.pdf
works fine. The surprise is that, in the listener, the phrase:

"cd /path/to/1_long_gu ; docsplit text --no-clean -l chi_sim
long_gu001.pdf" run-process .

- returns with status 0, but leaves no file. Ditto using /full/path/to/docsplit
in the command.

The docsplit bin alias (/usr/local/opt/ruby/bin/docsplit) resolves
to /usr/local/Cellar/ruby/2.1.0/bin/docsplit
(installed w/ homebrew). There I find this ruby script:

require 'rubygems'

version = ">= 0"

if ARGV.first
  str = ARGV.first
  str = str.dup.force_encoding("BINARY") if str.respond_to? :force_encoding
  if str =~ /\A_(.*)_\z/
    version = $1
    ARGV.shift
  end
end

gem 'docsplit', version
load Gem.bin_path('docsplit', 'docsplit', version)

If I manage to decipher this, I'll try to translate it in Factor, and
invoke docsplit that way.
That should keep me busy for a while. Worth a try, though I know zip about
ruby. Once past
this boondoggle, I already have Factor code that walks the tree & collates
the files.

Thanks!
~cw




On Sun, Feb 9, 2014 at 4:31 AM, John Benediktsson <mrj...@gmail.com> wrote:

> If you get lost in path land you can always take a break and use the
> /full/path/to/docsplit.
>
> On Feb 9, 2014, at 2:03 AM, CW Alston <cwalsto...@gmail.com> wrote:
>
> Ah! Thanks, Joe-
> Great tip; should clear up the issue with "which". I am indeed starting
> Factor in the Finder. I'll try adjusting the plist.
> Maybe that even has something to do with my docsplit puzzle. Since I can
> address commands like couchdb
> via a <process>, I should be able to invoke docsplit that way as well,
> even though htop shows me that docsplit
> itself spawns sub-processes, like poppler & tesseract, to do its
> extraction work. Interesting.
>
> I'll go study the Mac dev doc you point to, & see what I can glean from
> there.
>
> Back to the books,
> ~cw
>
>
>
>
>
> On Sat, Feb 8, 2014 at 10:27 PM, Joe Groff <arc...@gmail.com> wrote:
>
>> On Sat, Feb 8, 2014 at 7:30 PM, CW Alston <cwalsto...@gmail.com> wrote:
>>
>>> Hi -
>>> Ok, I've upgraded using factor-macosx-x86-32-2013-07-25-14-21.dmg,
>>> still Version 0.97. Same issue with Factor's "which":
>>>
>>> IN: scratchpad USE: tools.which
>>> IN: scratchpad "couchdb" which .
>>> f
>>>
>>> IN: scratchpad "python" which .
>>> "/usr/bin/python"
>>>
>>> - The trouble appears to be with reporting my PATH properly, via getenv:
>>>
>>> IN: scratchpad USE: environment
>>> IN: scratchpad "PATH" os-env .
>>> "/usr/bin:/bin:/usr/sbin:/sbin"
>>>
>>> IN: scratchpad USE: unix.ffi
>>> IN: scratchpad "PATH" getenv .
>>> "/usr/bin:/bin:/usr/sbin:/sbin"
>>>
>>> IN: scratchpad \ getenv see
>>> USING: alien.c-types alien.syntax ;
>>> IN: unix.ffi
>>> LIBRARY: libc FUNCTION: c-string getenv ( c-string name ) ;
>>>     inline
>>>
>>> - Here's my actual PATH, as seen in the terminal:
>>>
>>> ➜  ~ git:(master) ✗ echo $PATH
>>>
>>> /usr/local/bin:/usr/local/opt/ruby/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/cwalston/factor:/Users/cwalston/bin:/usr/local/go/bin:/usr/local/lib/node_modules:/usr/local/narwhal/bin:/usr/texbin:/usr/X11/bin:/usr/local/sbin:/Users/cwalston/.gem/ruby/1.8/bin:/Applications/Mozart.app/Contents/Resources/bin
>>>
>>> - whereby which correctly finds couchdb:
>>>
>>> ➜  ~ git:(master) ✗ which couchdb
>>> /usr/local/bin/couchdb
>>>
>>> So, Factor's "which" (et al.) doesn't search beyond
>>> /usr/bin:/bin:/usr/sbin:/sbin.
>>>
>>> Reading through man getenv (GETENV(3), on OSX 10.6.8 ), doesn't give me
>>> a clue as to how to rectify this short-sightedness via the libc getenv.
>>>
>>> This is probably a side issue to my docsplit quandary (but maybe not).
>>> Anyone see a way to report my actual PATH to "which" in Factor? My PATH
>>> is
>>> augmented in my .zshrc. I don't understand why the libc function doesn't
>>> read it. Odd, indeed!
>>>
>>> If you're starting Factor from the Finder, you're not going to get a
>> PATH set from your .profile or other shell dotfiles, since UI apps are
>> launched under the loginwindow session and not under any shell. To set
>> environment variables for UI apps, try setting them in
>> ~/.MacOSX/environment.plist:
>>
>>
>> https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html
>>
>> -Joe
>>
>
>
>
> --
> *~ Memento Amori*
>
>


-- 
*~ Memento Amori*
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Reply via email to