The ASCII code for the Ctrl+A character is 01, so I would try something like
this:
cmd = chr(01) + " SWITCH ON 01 02"
Then send the cmd string. If you need to convert a single-character string
back to an ASCII code, you would use the ord function.
On Tue, Oct 6, 2009 at 11:12 PM, Aloysius Jegan
Hi,
How to give Ctrl+A as a start of string in Ironpython?
My requirement is like this,
I have to send one command to my device assume the command is "SWITCH ON
01 02 03"
before sending this command through serial port, I have to press Ctrl+A as
start of command. I don't know how to add Ctrl+A
Thanks for the info
-Aloysius Jegan
Seo Sanghyeon
Sent by: users-boun...@lists.ironpython.com
10/07/2009 04:12 AM
Please respond to
Discussion of IronPython
To
Discussion of IronPython
cc
Subject
Re: [IronPython] NTLM authentication
2009/10/6 Aloysius Jegan :
> If any one know how
On Tue, Oct 6, 2009 at 11:53 AM, Giles Thomas
wrote:
> Michael Foord wrote:
>>
>> (I'm honestly not sure how creating a writable directory is a security
>> issue?)
>
> I suspect people are thinking of an attack where an untrusted user installs
> a package that looks like a normal one, but actually
2009/10/6 Aloysius Jegan :
> If any one know how to do NTLM authentication from IronPython, please send
> me the procedure or share the code if you have it.
In IronPython you have a choice of doing it like Python or like .NET.
For Python,
this library provides NTLM authentication for urllib2.
htt
Dino Viehland wrote:
Michael wrote:
Well, fair enough [1]. :-)
Except it may *still* leave distutils / package management basically
unusable for many people. That would still seem to be bad. I'd like to
work on making Distribute (the successor to setuptools) compatible with
IronPython but it
This is an automated email letting you know that sources
have recently been pushed out. You can download these newer
sources directly from
http://ironpython.codeplex.com/SourceControl/changeset/view/59799.
MODIFIED SOURCES
$/IronPython/IronPython_2_6/Src/IronPython/Compiler/Ast/Functi
Michael wrote:
> Well, fair enough [1]. :-)
>
> Except it may *still* leave distutils / package management basically
> unusable for many people. That would still seem to be bad. I'd like to
> work on making Distribute (the successor to setuptools) compatible with
> IronPython but it is going to re
Dino Viehland wrote:
Michael wrote:
I still see it as a question of usability rather than security. (I'm
honestly not sure how creating a writable directory is a security
issue?) If the default install location of IronPython makes installing
and using Python packages with IronPython impossibl
Michael Foord wrote:
(I'm honestly not sure how creating a writable directory is a security
issue?)
I suspect people are thinking of an attack where an untrusted user
installs a package that looks like a normal one, but actually does
something nefarious like install a rootkit (and perhaps does
Michael wrote:
> I still see it as a question of usability rather than security. (I'm
> honestly not sure how creating a writable directory is a security
> issue?) If the default install location of IronPython makes installing
> and using Python packages with IronPython impossible for non-elevated
Giles Thomas wrote:
Dino Viehland wrote:
But it seems like CPython is the one who's doing something wrong here.
Another data point; easy_install under CPython using Vista with UAC
switched on tries to escalate permissions as you would expect -- the
normal grey screen, "please enter an admin
Dino Viehland wrote:
But it seems like CPython is the one who's doing something wrong here.
Another data point; easy_install under CPython using Vista with UAC
switched on tries to escalate permissions as you would expect -- the
normal grey screen, "please enter an administrator's details" t
Michael wrote:
> Dino Viehland wrote:
> > Michael wrote:
> >
> >> Curt Hagenlocher wrote:
> >>
> >>> In principle, allowing unprivileged users to install code into a
> >>> location where it can unknowingly be accessed by privileged users is a
> >>> security problem. A "per-user" approach is the rig
Jeff Hardy wrote:
On Tue, Oct 6, 2009 at 10:53 AM, Michael Foord
wrote:
The first succeeds, naturally. Are you saying that it would be *more*
surprising if the second succeeded?
It should be surprising - a limited user should *never* be able to
install software into a shared location.
On Tue, Oct 6, 2009 at 10:53 AM, Michael Foord
wrote:
> The first succeeds, naturally. Are you saying that it would be *more*
> surprising if the second succeeded?
It should be surprising - a limited user should *never* be able to
install software into a shared location. The fact that it works fo
Dino Viehland wrote:
Michael wrote:
Curt Hagenlocher wrote:
In principle, allowing unprivileged users to install code into a
location where it can unknowingly be accessed by privileged users is a
security problem. A "per-user" approach is the right one.
Unknowingly?
I've
Dino Viehland wrote:
Michael wrote:
I don't have an obvious solution (per user site-packages perhaps?) but
present the problem. Python circumvents this problem by *not* installing
into "Program Files".
I would actually say that CPython seems to circumvent this by allowing
users to writ
Dino Viehland wrote:
Michael wrote:
Curt Hagenlocher wrote:
In principle, allowing unprivileged users to install code into a
location where it can unknowingly be accessed by privileged users is a
security problem. A "per-user" approach is the right one.
Unknowingly?
I've
Michael wrote:
> Curt Hagenlocher wrote:
> > In principle, allowing unprivileged users to install code into a
> > location where it can unknowingly be accessed by privileged users is a
> > security problem. A "per-user" approach is the right one.
>
> Unknowingly?
I've just installed some software
Michael wrote:
> I don't have an obvious solution (per user site-packages perhaps?) but
> present the problem. Python circumvents this problem by *not* installing
> into "Program Files".
I would actually say that CPython seems to circumvent this by allowing
users to write to its installation direc
This is an automated email letting you know that sources
have recently been pushed out. You can download these newer
sources directly from
http://ironpython.codeplex.com/SourceControl/changeset/view/59795.
MODIFIED SOURCES
$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonTrac
Curt Hagenlocher wrote:
In principle, allowing unprivileged users to install code into a
location where it can unknowingly be accessed by privileged users is a
security problem. A "per-user" approach is the right one.
Unknowingly?
Michael
On Tue, Oct 6, 2009 at 4:45 AM, Michael Foord
mail
In principle, allowing unprivileged users to install code into a location
where it can unknowingly be accessed by privileged users is a security
problem. A "per-user" approach is the right one.
On Tue, Oct 6, 2009 at 4:45 AM, Michael Foord wrote:
> Hello guys,
>
> The msi installer installs by de
On Tue, Oct 6, 2009 at 06:45, Michael Foord wrote:
> Hello guys,
>
> The msi installer installs by default into "C:\Program Files\IronPython
> 2.6". It also creates a "Lib\site-packages" folder.
>
> Presumably the intention is that site-packages is for installed modules /
> packages, however "Prog
Hi,
If any one know how to do NTLM authentication from IronPython, please send
me the procedure or share the code if you have it.
Thanks.
Regards,
Aloysius Jegan E.A.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listi
Hello guys,
The msi installer installs by default into "C:\Program Files\IronPython
2.6". It also creates a "Lib\site-packages" folder.
Presumably the intention is that site-packages is for installed modules
/ packages, however "Program Files" is a special location and normal
users (Vista /
27 matches
Mail list logo
