Jason - thanks for replying
and I concur, it makes sense to open a JIRA for this. I'm glad there is
an acceptable workaround, at least.
I recall doing a fair bit of trial and error, asking 'nix folk and
stackoverflow how to handle this stdin situation and honing in on what's there
now. But it's obviously weirdly broken, sorry.
Erik
> On Apr 14, 2019, at 8:30 AM, Jason Gerlowski <gerlowsk...@gmail.com> wrote:
>
> Hi Carsten,
>
> I think this is probably worth a jira. I'm not familiar enough with
> bin/post to say definitively whether the behavior you mention is a
> bug, or whether it's "expected" in some odd sense. But there's enough
> uncertainty that I think it's worth recording there.
>
> Best,
>
> Jason
>
> On Fri, Apr 12, 2019 at 5:52 AM Carsten Agger <carst...@magenta.dk> wrote:
>>
>> Hi all
>>
>> I posted the question below some time back, concerning the unusual
>> behaviour of bin/post if there is no stdin.
>>
>> There has been no comments to that, and maybe bin/post is quaint in that
>> regard - I ended up changing my application to POST directly on the Web
>> endpoint instead.
>>
>> But I do have one question, though: Should this be considered a bug, and
>> should I report it as such? Unfortunately I don't have the time to
>> prepare a proper fix myself.
>>
>> Best
>> Carsten
>>
>> On 3/27/19 7:55 AM, Carsten Agger wrote:
>>> I'm working with a script where I want to send a command to delete all
>>> elements in an index; notably,
>>>
>>>
>>> /opt/solr/bin/post -c <my collection> -d
>>> "<delete><query>*:*</query></delete>"
>>>
>>>
>>> When run interactively, this works fine.
>>>
>>> However, when run automatically as a cron job, it gives this interesting
>>> output:
>>>
>>>
>>> Unrecognized argument: "<delete><query>*:*</query></delete>"
>>>
>>> If this was intended to be a data file, it does not exist relative to /root
>>>
>>> The culprit seems to be these lines, 143-148:
>>>
>>> if [[ ! -t 0 ]]; then
>>> MODE="stdin"
>>> else
>>> # when no stdin exists and -d specified, the rest of the arguments
>>> # are assumed to be strings to post as-is
>>> MODE="args"
>>>
>>> This code seems to be doing the opposite of what the comment says - it
>>> sets MODE="stdin" if stdin is NOT a terminal, but if it IS (i.e., there
>>> IS an stdin) it assumes the rest of the args can be posted as-is.
>>>
>>> On the other hand, if the condition is reversed, my command will fail
>>> interactively but not when run as a cron job. Both options are, of
>>> course, unsatisfactory.
>>>
>>> It /will/ actually work in both cases, if instead the command to delete
>>> the contents of the index is written as:
>>>
>>> echo "<delete><query>*:*</query></delete>" | /opt/solr/bin/post -c
>>> departments -d
>>>
>>>
>>> I've seen this bug in SOLR 7.5.0 and 7.7.1. Should I report it as a bug
>>> or is there an easy explanation?
>>>
>>>
>>> Best
>>>
>>> Carsten Agger
>>>
>>>
>> --
>> Carsten Agger
>>
>> Chief Technologist
>> Magenta ApS
>> Skt. Johannes Allé 2
>> 8000 Århus C
>>
>> Tlf +45 5060 1476
>> http://www.magenta-aps.dk
>> carst...@magenta-aps.dk
>>
