As a follow-up, from Factor you can use `with-directory-files`
(http://docs.factorcode.org/content/word-with-directory-files,io.directories.html)
and `absolute-path`
(http://docs.factorcode.org/content/word-absolute-path,io.pathnames.html)
to get full paths to the files in some directory:
```
IN: scratchpad "/home/alex/factor/core" [ [ absolute-path . ] each ]
with-directory-files
"/home/alex/factor/core/generic"
"/home/alex/factor/core/parser"
"/home/alex/factor/core/sorting"
[etc]
```
On Sun, Feb 9, 2014 at 1:53 PM, Alex Vondrak <ajvond...@gmail.com> wrote:
> It's probably easiest to specify the full path to the file, like I did
> in my previous message. Combined with the full path to the docsplit
> binary/link (for your particular problem), it should theoretically
> work fine:
>
> "/full/path/to/docsplit text --no-clean -l chi_sim
> /path/to/1_long_gu/long_gu001.pdf" try-process
>
> On Sun, Feb 9, 2014 at 1:00 PM, CW Alston <cwalsto...@gmail.com> wrote:
>> 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
>>
------------------------------------------------------------------------------
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
