KShell & KMacroExpander - are we screwed?

Andreas Pakulat apaku at gmx.de
Mon Oct 15 03:27:08 CEST 2007

On 15.10.07 01:09:15, Oswald Buddenhagen wrote:
> On Sun, Oct 14, 2007 at 11:27:37PM +0200, Andreas Pakulat wrote:
> > On 05.10.07 15:52:01, Oswald Buddenhagen wrote:
> > > possible solutions:
> > > - ignore the problem.
> > > - ban % from arguments.
> > > - screw cmd, v1: kprocess::setshellcommand is nuked again
> > > - screw cmd, v2: use a posix shell under windows
> > > 
> > > unless somebody has a better idea, i vote for screw cmd v2, and as a
> > > last resort v1 for windows only.
> > 
> > Well, I'm tempted to say: go for option 1 on win32. I mean if you manage
> > to get your environment screwed up who knows what else goes on on that
> > machine, it needs a reinstall anyway.
> > 
> that's oversimplifying the matter.

I guessed so :(

> - you might not need to crack the system to change the env. the
>   application might contain some bug that prods it into setenv()ing
>   something silly.

Well, a broken app can do all sorts of things, including rm -rf ~/Mail
when you switch the folder ;) I'm neither a cmd nor a sh guru, but I
suspect you can get an rm -rf / into a shell command as well with a bug
in the application.

> - while the potential security problem is the biggest one, it is not the
>   only one. one might get an expansion completely unexpectedly.

Sure, just the same if I happen to forget to escape the $ in $HOME
(where I actually wanted the literal string $HOME). Right, on win32 you
can't escape the % sign which means %HOME% always gets expanded, which
in turn means you can't use it inside a cmd-shell. That again means if
we want that to be possible we need a posix shell, see below for the
problems with that.

> > If thats not an option I think I vote for screw v1.
> >
> well, if this makes win devels happy ...
> but don't expect any unix devels to be considerate with your cripled
> platform.

s/your/theirs/ please, at least if you answer to my mails. Linux is _my_
platform, I just happen to like to use one or two kde apps on win32 :)
In this case even ones that won't need shell-features from KProcess
anyway (rather a embedded terminal ;)

> > screw v2 is still not an option,
> > it doesn't make anything simpler for win32 kde developers
> >
> well, it does by not requiring them to do any porting in some cases.

I wasn't talking about the people porting kde to win32, I was talking
about people using kde/win32 to create apps ;)

> > and especially not for the users. Those users would have to adopt the
> > commands and arguments to posix shell, which you can't really expect
> > from them.
> > 
> you should consider that about 99% of the commands the user ever
> supplies will look like "foo %f", etc.

If I recall correctly there %f won't be expanded, right? Also that 99%
are not from the whole userbase, but those that actually need to provide
a shell-thing somewhere, which IMHO is a rather small number of people
(compared to the whole kde/win32 userbase)

> it only becomes a problem if
> somebody tries to execute complex shell constructs. but those able to do
> that are also able to learn the posix equivalents

Actually I suspect those people that execute really complex shell
constructs on win32 use .bat files and don't try to write that down in a

> (it's not like cmd has a lot of stuff one needs to learn a replacement
> for :-P) and might even appreciate the considerably less braindead
> syntax rules. ;)

Maybe they would, otoh they're already used to that braindead shell and
possibly don't want to learn yet another thing.

Hmm, this discussion about the problems being rather
corner-case-situations for people that know their way around the win32
cmd shell makes me wanting to do solution 1) more and more (i.e. ignore
the problems)

> btw, i wouldn't go for bash as the posix shell - ash is much leaner -
> provided it runs with, e.g. mingw.
> why exactly is a cygwin-based shell is a no-go? ash + libc.dll +
> cygwin.dll (or whatever that might be in the end) isn't really a heavy
> set of deps.

One problem with cygwin is that its using unix-paths (dunno if thats
also true for winbash, but I hope not), which creates problems when used
in your cmake/win32 build environment. Or not? (@win32 people: does
kde/win32 use \ or / in user-visible paths?)

God, I'm really long time no-win32 user anymore. 4 years ago I knew my
way around all this, nowadays its all black magic again :(


You are fighting for survival in your own sweet and gentle way.

More information about the Kde-windows mailing list