tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Proposal to add /usr/bin/shquote

Aleksej Saushev <> writes:

> Alan Barrett <> writes:
>> On Sat, 06 Sep 2008, Aleksej Saushev wrote:
>>> > I often find the need, in shell scripts, to escape arguments to be
>>> > passed to other shell commands.  I'd like to add a /usr/bin/shquote
>>> > command as a simple wrapper around shquotev(3) to do this.
>>> Why not import real programming language for that? TCL, for instance.
>> So your solution would be to have my shell script do something like
>> this:
>>      listvar="$( tclsh /wherever/somescript arg1 arg2 )"
>> instead of what I can already do using my own shell function or shell
>> script (invoking sed(1) and printf(1)), or what I propose to do using a
>> compiled C program (invoking shquotev(3)):
>>      listvar="$( shquote arg1 arg2 )"
>> Your solution would require both writing the tcl script, and importing
>> tcl to the NetBSD base system.  I don't see that as any simpler than what
>> I proposed.
> It is. I assure you, that it is better to learn TCL than
> fighting shell quotations, sed, test, and company.
> It is simpler and faster, and doesn't involve ad hoc C-written
> tools for subtasks, when it becomes too hard to continue with sh.
> Importing TCL is one-time task. Yes, it is big task, I know that
> pretty well, but it saves your time in future.

I'll add.

All these PERL/anti-PERL wars arise from simple fact that sh & co
is not enough. PERL is the first obvious tool that is sufficiently
powerful. The first argument against PERL is its licensing.
But the latter is solved easily: just choose any tool with
proper licence. TCL is one of them, Lua is another, you can find
other possible languages. Thus the problem is resolved: you have
powerful enough tool (scripting language), and you stay
consistent in licence policy.


Home | Main Index | Thread Index | Old Index