OK, I've built my "cycling" GUI and I get all the data I want into a nice list, something like this: {WARM 5 30 80 100} {BLCK 30 0 150 85} {COOL 5 100 80 80}I never use that option, but I can imagine that the program then starts in a directory that is indeed protected. Can you print it - puts [pwd] - in the console?
Where WARM mean warmup and the figures are:
mins secs start_power end_power (I could have another figure at end for cadence, but optional).
So, I can read those and write to my workout file, then the steady block, then the cool-down. (I can have other more complex stuff like intervals that ramp up in power etc).
Now, I double click on WISH and get a wish & associated tcl shell, I "source" my top level file, and all works fine.
BUT, if I open my script by "open with" Wish Application, I get "permission denied" when I try to write my output file.
Is this something to do with Windows 10.
This is the last step that I need to get it all to work.
On Friday, November 11, 2022 at 10:47:47 AM UTC+1, snosniv wrote:
OK, I've built my "cycling" GUI and I get all the data I want into a nice list, something like this: {WARM 5 30 80 100} {BLCK 30 0 150 85} {COOL 5 100 80 80}
Where WARM mean warmup and the figures are:
mins secs start_power end_power (I could have another figure at end for cadence, but optional).
So, I can read those and write to my workout file, then the steady block, then the cool-down. (I can have other more complex stuff like intervals that ramp up in power etc).
Now, I double click on WISH and get a wish & associated tcl shell, I "source"
my top level file, and all works fine.
BUT, if I open my script by "open with" Wish Application, I get "permission denied" when I try to write my output file.
Is this something to do with Windows 10.
This is the last step that I need to get it all to work.
I never use that option, but I can imagine that the program then starts in a directory that is indeed protected. Can you print it - puts [pwd] - in the console?
Regards,
Arjen
On Friday, November 11, 2022 at 10:47:47 AM UTC+1, snosniv wrote:
OK, I've built my "cycling" GUI and I get all the data I want into a nice list, something like this: {WARM 5 30 80 100} {BLCK 30 0 150 85} {COOL 5 100 80 80}
Where WARM mean warmup and the figures are:
mins secs start_power end_power (I could have another figure at end for cadence, but optional).
So, I can read those and write to my workout file, then the steady block, then the cool-down. (I can have other more complex stuff like intervals that ramp up in power etc).
Now, I double click on WISH and get a wish & associated tcl shell, I "source"
my top level file, and all works fine.
BUT, if I open my script by "open with" Wish Application, I get "permission denied" when I try to write my output file.
Is this something to do with Windows 10.I never use that option, but I can imagine that the program then starts in a directory that is indeed protected. Can you print it - puts [pwd] - in the console?
This is the last step that I need to get it all to work.
Regards,
Arjen
* snosniv <nivpa...@gmail.com>OK, thanks, will try that.
| proc build_workout {} {
| global fname
| set fout_name "CLUB_$fname.txt"
Might be a good idea to include the full path of the file instead of
relying on where the app starts by coincidence:
set fout_name "c:/where/the/files/should/go/CLUB_$fname.txt"
Maybe make the directory part configurable.
R'
On Friday, 11 November 2022 at 12:35:23 UTC, Ralf Fassel wrote:
* snosniv <nivpa...@gmail.com>OK, thanks, will try that.
| proc build_workout {} {
| global fname
| set fout_name "CLUB_$fname.txt"
Might be a good idea to include the full path of the file instead of
relying on where the app starts by coincidence:
set fout_name "c:/where/the/files/should/go/CLUB_$fname.txt"
Maybe make the directory part configurable.
R'
However, I've just found that if I "freewrap" myfiles into a single executable, it works, which was my final goal.
BUT, I will try your suggestion as I'd like to know why it worked or
not depending on how invoked!
snosniv <nivpa...@gmail.com> wrote:
On Friday, 11 November 2022 at 12:35:23 UTC, Ralf Fassel wrote:If you were really trying to load files by relative name (your set
* snosniv <nivpa...@gmail.com>OK, thanks, will try that.
| proc build_workout {} {
| global fname
| set fout_name "CLUB_$fname.txt"
Might be a good idea to include the full path of the file instead of
relying on where the app starts by coincidence:
set fout_name "c:/where/the/files/should/go/CLUB_$fname.txt"
Maybe make the directory part configurable.
R'
However, I've just found that if I "freewrap" myfiles into a single executable, it works, which was my final goal.
BUT, I will try your suggestion as I'd like to know why it worked or
not depending on how invoked!
fout_name) above has no directory string, so it is a "relative" name)
then whether the "open" succeeds depends upon what "default directory"
is used to look for the files.
That "default directory" being the "current working directory" which
you can retreive using the "pwd" command (most likely short for (P)rint (W)orking (D)irectory).
Upon startup, your script is assigned a current working directory by
the OS. MSWin seems to like to assign different current working
directories depending upon whether you launch from a cmd shell, a
shortcut, or let windows file extension lookup pick an executable.
The failures were likely due to MSWin giving you a current working
directory that was different from the directory where your scripts were stored. So if your scripts were stored at c:\user\snosiv\script\ but
windows gave the process a current working directory of
c:\programs\tcl\bin then all your relative file accesses were looking
in c:\programs\tcl\bin for the filenames your script was trying to
open, and as they were not there, all the opens failed.
On Friday, 11 November 2022 at 22:14:13 UTC, Rich wrote:
snosniv <nivpa...@gmail.com> wrote:
On Friday, 11 November 2022 at 12:35:23 UTC, Ralf Fassel wrote:If you were really trying to load files by relative name (your set fout_name) above has no directory string, so it is a "relative" name)
* snosniv <nivpa...@gmail.com>OK, thanks, will try that.
| proc build_workout {} {
| global fname
| set fout_name "CLUB_$fname.txt"
Might be a good idea to include the full path of the file instead of
relying on where the app starts by coincidence:
set fout_name "c:/where/the/files/should/go/CLUB_$fname.txt"
Maybe make the directory part configurable.
R'
However, I've just found that if I "freewrap" myfiles into a single executable, it works, which was my final goal.
BUT, I will try your suggestion as I'd like to know why it worked or
not depending on how invoked!
then whether the "open" succeeds depends upon what "default directory"
is used to look for the files.
That "default directory" being the "current working directory" which
you can retreive using the "pwd" command (most likely short for (P)rint (W)orking (D)irectory).
Upon startup, your script is assigned a current working directory by
the OS. MSWin seems to like to assign different current working
directories depending upon whether you launch from a cmd shell, a
shortcut, or let windows file extension lookup pick an executable.
The failures were likely due to MSWin giving you a current working directory that was different from the directory where your scripts were stored. So if your scripts were stored at c:\user\snosiv\script\ but windows gave the process a current working directory ofThanks Rich, it's definitely something to do with the path.
c:\programs\tcl\bin then all your relative file accesses were looking
in c:\programs\tcl\bin for the filenames your script was trying to
open, and as they were not there, all the opens failed.
After a bit of debugging this morning, I invoked my script from where it resides in C:\ActiveTcl\User_files\CYCLE
with the "Open with Wish application" after I added the following code:
set my_path [pwd]
set my_name "CLUB_$woname.zwo" ;# woname is set in an entry box, in this instance as "testwr"
set f_out [open $my_path/$my_name w]
And I get this message:
couldn't open "C:/Windows/System32/CLUB_testwr.zwo": permission denied.
So, I now see what's going on, thanks for the help in resolving that. :-) BUT, I want to keep the script flexible such that whatever directory it's in, file writes are to the same directory, I don't want to put a hard path to the directory.
I'm sure it's a simple fix, but can't seem to sort the wood from the trees.
Thanks, Kev P.
On Friday, 11 November 2022 at 22:14:13 UTC, Rich wrote:
snosniv <nivpa...@gmail.com> wrote:
BUT, I will try your suggestion as I'd like to know why it worked
or not depending on how invoked!
If you were really trying to load files by relative name (your set
fout_name) above has no directory string, so it is a "relative"
name) then whether the "open" succeeds depends upon what "default
directory" is used to look for the files.
That "default directory" being the "current working directory" which
you can retreive using the "pwd" command (most likely short for
(P)rint (W)orking (D)irectory).
Upon startup, your script is assigned a current working directory by
the OS. MSWin seems to like to assign different current working
directories depending upon whether you launch from a cmd shell, a
shortcut, or let windows file extension lookup pick an executable.
The failures were likely due to MSWin giving you a current working
directory that was different from the directory where your scripts
were stored. So if your scripts were stored at
c:\user\snosiv\script\ but windows gave the process a current
working directory of c:\programs\tcl\bin then all your relative file
accesses were looking in c:\programs\tcl\bin for the filenames your
script was trying to open, and as they were not there, all the opens
failed.
Thanks Rich, it's definitely something to do with the path.
After a bit of debugging this morning, I invoked my script from where
it resides in C:\ActiveTcl\User_files\CYCLE with the "Open with Wish application" after I added the following code:
set my_path [pwd]
set my_name "CLUB_$woname.zwo" ;# woname is set in an entry box, in this instance as "testwr"
set f_out [open $my_path/$my_name w]
And I get this message:
couldn't open "C:/Windows/System32/CLUB_testwr.zwo": permission denied.
So, I now see what's going on, thanks for the help in resolving that. :-) BUT, I want to keep the script flexible such that whatever directory it's in, file writes are to the same directory, I don't want to put a hard path to the directory.
I'm sure it's a simple fix, but can't seem to sort the wood from the trees.
snosniv <nivpa...@gmail.com> wrote:
On Friday, 11 November 2022 at 22:14:13 UTC, Rich wrote:
snosniv <nivpa...@gmail.com> wrote:
BUT, I will try your suggestion as I'd like to know why it worked
or not depending on how invoked!
If you were really trying to load files by relative name (your set
fout_name) above has no directory string, so it is a "relative"
name) then whether the "open" succeeds depends upon what "default
directory" is used to look for the files.
That "default directory" being the "current working directory" which
you can retreive using the "pwd" command (most likely short for
(P)rint (W)orking (D)irectory).
Upon startup, your script is assigned a current working directory by
the OS. MSWin seems to like to assign different current working
directories depending upon whether you launch from a cmd shell, a
shortcut, or let windows file extension lookup pick an executable.
The failures were likely due to MSWin giving you a current working
directory that was different from the directory where your scripts
were stored. So if your scripts were stored at
c:\user\snosiv\script\ but windows gave the process a current
working directory of c:\programs\tcl\bin then all your relative file
accesses were looking in c:\programs\tcl\bin for the filenames your
script was trying to open, and as they were not there, all the opens
failed.
Thanks Rich, it's definitely something to do with the path.
After a bit of debugging this morning, I invoked my script from where
it resides in C:\ActiveTcl\User_files\CYCLE with the "Open with Wish application" after I added the following code:
set my_path [pwd]
set my_name "CLUB_$woname.zwo" ;# woname is set in an entry box, in this instance as "testwr"
set f_out [open $my_path/$my_name w]
And I get this message:
couldn't open "C:/Windows/System32/CLUB_testwr.zwo": permission denied.
So, I now see what's going on, thanks for the help in resolving that. :-) BUT, I want to keep the script flexible such that whatever directory it's in,
file writes are to the same directory, I don't want to put a hard path to the directory.
I'm sure it's a simple fix, but can't seem to sort the wood from the trees.It is a simple fix, and there are two simple ways to fix it.
For Tcl code files, one fix is to make the files you are sourcing into packages or modules (read the 'package' or 'tm' man pages) and then add
the location of the packages or modules to the auto_path or tm::path add
and then 'package require' the additional code.
The second fix, is to ask Tcl where the main script file is located,
and use that path for opening all the other files. And if you plan to
write files where the script resides, then this is your only option.
To do this you do:
# somewhere early in startup, you grab the directory part of the
# location of the script itself
set script_dir [file dirname [info script]]
# then, everywhere you 'source' a script file or open a file to write
# into, you do this, instead of what you have been doing:
set my_name "CLUB_$woname.zwo" ;# woname is set in an entry box, in this instance as "testwr"
set f_out [open [file join $script_dir $my_name] {WRONLY CREAT TRUNC}]
And your file 'CLUB_$woname.zwo' will be created in the same directory
where your script resides. For accessing/creating files in sub-directories, do:
set f_out [open [file join $script_dir $special_sub_dir $my_name] {WRONLY CREAT TRUNC}]
Note also, when combining paths and filenames, it is best to use
[file join ...] as it will take care of any of the various platform differences.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 498 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 26:26:38 |
| Calls: | 9,829 |
| Calls today: | 8 |
| Files: | 13,761 |
| Messages: | 6,192,125 |