Re: do. command. safety. ?

The user input was indirected through a variable in the safe version - not made part of the do string... That's the critical difference. The unsafe version allows user input to change the do'd code, the safe version only changes the content of a variable the do string uses. Warmest Regards,

Browser Widget Document Download

I have a url(that does not directly reference a file) that on iOS displays a PDF in the iOS native PDF viewer and on Android Downloads the PDF as Android has no native PDF viewer. I would like to download the PDF at all times. Testing in the IDE... When I set the widget to the url the PDF

Re: variable xref

Mark Wieder wrote: > A good question to ask here might be "what are the pain points of the > language as it now exists?" For me performance is a pain point. If I can demonstrate LC is at least on par with other scripting languages I get a foot in the door. But in server work performance

Re: do. command. safety. ?

Tom Glod wrote: > Sometimes late at night just before falling asleep I think about > the dangers of the do command. Is it possible to inject code into > this mechanism through malware? Mark's discussion handled the security aspect well. The only thing I could add would be to examine each

Re: variable xref

Hence my original statement about the xTalk language trying to be English like. (Back then I don't think Hypercard was multi-language). Bob S > On Mar 30, 2018, at 10:53 , Mikey via use-livecode > wrote: > > When I was thinking about unquoted literals I was

Re: do. command. safety. ?

Well yes, but as Bob mentioned, wouldn't a variable do the same thing? put ";delete hard drive;put " into x do x vs: do "put " && quote & ";delete hard drive;put " & quote && "into x" This actually came up way back in MetaCard where it was pointed out that the engine was about as

Re: variable xref

When I was thinking about unquoted literals I was thinking about string literals, something like put one into counter Or put one into two Numeric literals don’t offend the senses: put 1 into counter In the case of property assignments I could be persuaded either way: that there is a global

Re: do. command. safety. ?

Couldn't the same be said about tVar? I suppose you mean that you could check the user input before doing it. Bob S > On Mar 30, 2018, at 10:15 , Mark Waddingham via use-livecode > wrote: > > Think about the string that can be constructed in the quoted version

Re: variable xref

We have computers automate these processes, but always with a human ready to intervene. The computer will act based upon the inputs it receives. If the inputs go wrong, you may have an exceptional diagnostic routine running to detect it and act accordingly, but only a human can make a judgement

Re: do. command. safety. ?

Think about the string that can be constructed in the quoted version - user input could be "; ...;put " where ... is any code you would like... Sent from my iPhone > On 30 Mar 2018, at 18:09, J. Landman Gay via use-livecode > wrote: > > These look the same to

Re: do. command. safety. ?

These look the same to me. Both versions place content into a variable. Is the difference because of how the engine evaluates the input somehow? -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On March 30, 2018 11:04:54 AM Mark Waddingham

Re: do. command. safety. ?

your point still applies about not being responsible that the user has allowed malware onto their system. On Fri, Mar 30, 2018 at 12:52 PM, Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > Ah I saw command in the subject and thought you were talking about shell > commands.

Re: do. command. safety. ?

Ah I saw command in the subject and thought you were talking about shell commands. Bob S > On Mar 30, 2018, at 09:49 , Tom Glod via use-livecode > wrote: > > Valid point Bob. Thank You. > > Useful info, Thanks Mark. I was doing it the right way

Re: variable xref

That's pretty much my point of view - the compiler should keep you out of trouble but not get in the way. Colours are the same case as left in the context of textAlign. If we reserved all lowercase alphabetic identifiers, so your vars had to contain an uppercase letter or non letter character

Re: do. command. safety. ?

Valid point Bob. Thank You. Useful info, Thanks Mark. I was doing it the right way sometimes. the wrong way other times. thank you. On Fri, Mar 30, 2018 at 12:02 PM, Mark Waddingham via use-livecode < use-livecode@lists.runrev.com> wrote: > Using do safely is the same as making database

Re: variable xref

I think we are not seeing the elephant in the room here. Programming languages work because a great deal of effort has been exherted defining what we MEAN when we SAY something to the computer. In fact the whole process of writing software is precicely that of removing all ambiguity. It's true

Re: variable xref

On 03/30/2018 08:56 AM, Mark Waddingham via use-livecode wrote: I'd suggest that the language doesn't matter - so 'natural language like' would perhaps be a better term but even then is that really what we mean? A good question to ask here might be "what are the pain points of the language

Re: do. command. safety. ?

Using do safely is the same as making database queries safe, or URL requests. You 'just' need to make sure that any input from outside is sanitized to ensure that it doesn't change the meaning of the expression you are 'doing'. For example, don't interpolate strings directly in the script using

Re: variable xref

An important question to ask here is 'what do we mean by English-like'? I'd suggest that the language doesn't matter - so 'natural language like' would perhaps be a better term but even then is that really what we mean? There's no inherent difference (formally at least) between a programming

Re: do. command. safety. ?

Any shell command that can do anything dangerous is typically protected by the host OS. You could not for example install software in a way that would bypass UAC in Windows. You *could* conceivably delete all the files in a folder I suppose, but you couldn't copy files to a protected location.

do. command. safety. ?

Dear Geniuses Sometimes late at night just before falling asleep I think about the dangers of the do command. Is it possible to inject code into this mechanism through malware? I do not have enough understanding of operating systems and their processes ...and the livecode engineto be

Re: Blurring field contents

Or cover the hidden fields with graphics of daisies. :-) Bob S > On Mar 30, 2018, at 08:40 , J. Landman Gay via use-livecode > wrote: > > Or make a generic "blur" image in a graphics program and overlay it on the > fields when needed.

Re: Blurring field contents

Or make a generic "blur" image in a graphics program and overlay it on the fields when needed. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On March 30, 2018 9:07:48 AM Rick Harrison via use-livecode

Re: variable xref

I agree. The goal was to make computing as english like as possible, but the take away to that great experiment is that one can only go so far. People interpret what a person may mean. Computers do not have that luxury. Still xTalk is a magnificient accomplishment. Bob S > On Mar 29, 2018,

Re: Blurring field contents

You could also make up bogus text data to show instead of using real data. Rick > On Mar 29, 2018, at 11:48 PM, scott--- via use-livecode > wrote: > > If blurring turns out to be too problematic you might consider just replacing > text with bullets or Lorem

Re: variable xref

On Mar 29, 2018, at 10:34 PM, Mike Kerner via use-livecode wrote: > > I don't want to pretend to be an expert on the topic of writing compilers, > since I only ever wrote two, both under the watchful obsession of a > professor, and my lex and parse code were not