Is it possible to change file permissions within Rebol 3 without relying on CALLing CHMOD? Rebol 2 had 'set-modes though doesn't appear to be available any longer:
permissive-access: [
owner-read: group-read: world-read:
owner-write: group-write: world-write: #[true]
owner-execute: group-execute: world-execute: #[false]
]
set-modes file permissive-access
At the moment, no, you have to use call.
It is planned to add back the port mode getting and setting capabilities, but the API needs a revamp first and we haven't started the discussion for that yet. The port model is mostly different in Rebol 3, so the port mode model is going to have to be different too. Feel free to get the discussion started.
Related
I'm trying to vusb-analyzer.
It requires *.mon log file.
How can I make usbmon log file (*.mon)?
https://www.kernel.org/doc/Documentation/usb/usbmon.txt
The document you linked in your question is actually the answer, please see the sections 1-3.
In section 3, it says:
# cat /sys/kernel/debug/usb/usbmon/0u > /tmp/1.mon.out
This will create a text file 1.mon.out. Its structure is also described in the same document.
Now, how do I know that this is the file to be opened by vusb-analyzer? From what I see, the website of this project doesn't make it clear what the *.mon file is.
However, you can see it in the source code:
https://github.com/scanlime/vusb-analyzer/blob/master/VUsbTools/Log.py#L498
It clearly states, that the program uses the syntax described in the document that you already know:
https://www.kernel.org/doc/Documentation/usb/usbmon.txt
The name of your file doesn't really matter, but if you want it to end with ".mon", you could simply use:
# cat /sys/kernel/debug/usb/usbmon/0u > ~/somefile.mon
Two warnings:
The line with cat I posted here is just an example and in order to use it, you will need to follow the steps in the document (it won't work without enabling usbmon first)
vusb-analyzer hasn't been updated for years and I wasn't able to run it on my machine. Its website mentions Ubuntu 8.10 so I wouldn't be surprised if others had problems running it, too. (For example, in order to reproduce your problem, provide more help).
I am needing to use Puppet to create windows shortcuts on hosts to be accessed via SAMBA. The Puppet side I'll be fine with, it's the script I've been having issues getting working.
I've tried to use:
mslink_v1.3.sh (http://www.mamachine.org/mslink/index.en.html)
pylnk3.py (https://pypi.org/project/pylnk3)
lnk.py (https://github.com/blacklanternsecurity/mklnk)
mslink_v3.sh on first look covers it all, with the exception of what I need to do. Similar with pylnk3.sh and lnk.sh working together, just a different reason for it not to work.
I am trying to create a windows shortcut to a network location with a argument with a space in it. Example below:
Path to exe = \\myhostname\program.exe
Argument = \\myhostname\program.ini loadabc
mslink_v3.sh will not let me surround the argument in single or double quotes, but works fine for network locations. pylnk3.sh/lnk.sh will not work for network locations, argument with spaces are ok via quotes. I did find in the end a code reference in pylink3.sh that network locations have not been implemented yet.
I've not found away to contact the developer of mslink_v3.sh to see about a tweak. I was going to comment on his post on this site, but I did not have enough points (hoping this post may give me enough).
Any suggestions at this point would be good.
Thanks
Matt
I contacted the developer of pylnk3.py via GitHub. He's added network support and also added all the cli support that lnk.py added.
Link below to the branch with all the development included:
https://github.com/strayge/pylnk/tree/cli_options
Sorry if the title is a bit confusing, but what are the options/conventions that Origen provides for setting up subblocks that aren't necessarily silicon models, or are just general helpers?
For example, I have a scan helper plugin that guides the user through creating a scan test program. I'd like to add a list of options/customizations to the top-level app. There are a few ways to do this:
I can add a list of attr_readers/methods. I think this looks a bit ugly though and adds a bunch of stuff to the toplevel that isn't used by anything else, and it blows up $dut.methods.
I could use parameters as defined here: http://origen-sdk.org/origen/guides/models/parameters/ and just call of them in the scan tester app. But looking at the guides I don't think that is the desired use case. It looks more like context switching, but maybe that was just the example use case.
I could add a scan_tester.setup method or something on the toplevel. This just seems unnecessary though since its basically doing the same thing as #2, but requires a 'setup' method to be called. Yeah, its only 1 line, but if you mess up or forget to add that line then you've got some debug to do avoided by #2 (I can print a warning for example if the scan parameters aren't provided to help warn of typos, etc.).
I can set it up as a subblock (currently how I've got it), but this doesn't really fit. Scan isn't a silicon model, so base address is useless, but required. It has no registers, etc.
Then there's other 'Ruby' things I could do (setup via on_create, use global variable etc.) but these all seem not as great as any of the options above for one reason or another (mainly, more setup required on my part than using any of the existing options).
Any one of these would work. But from a convention standpoint, which direction should my scan tester setup go? Is there another option I hadn't considered? I'd lean towards option #2 as it looks the cleanest.
Thanks
This is a really good question.
There are actually two other options:
Add application config parameters from the plugin: http://origen-sdk.org/origen/release_notes/#v0_7_24
Define a constant as used by the JTAG and other early plugins: http://origen-sdk.org/jtag/#How_To_Use
I think #2 is using parameters in a way that was not originally intended, maybe it could work though but I just can't picture it.
I don't really like #5 or #6 since they provide application-level and class-level configuration, which is sometimes what you want, but often these days I see the need more for (DUT) instance-level configuration.
So, my best answer here is that I don't know, but you are touching on a good point that we need to have an official API or at least a recommendation for this.
I think you should be open to the possibility of adding something new to Origen for this if you can think of something better.
As I'm writing this, I suppose #5 would also support instance-level configuration, albeit a bit long-winded:
def initialize(options = {})
Origen.app.config.scan_chain_length = 6
end
My comment wouldn't keep its format, so here it is but looks better:
#Ginty
What would you think of a 'component' API. For example, we could have:
# components.rb
component(:scan, TIPScan::ScanTester,
# options
wgl_dir: ..., # defaults to Origen.app.root/pattern/wgl
custom_sort: proc do {|wgl_name| ...},
)
# then we can do things like:
$dut.scan #=> TIPScan instance
$dut.component(:scan) #=> same as above
$dut.components #=> [TIPScan instance, ...]
$dut.has_component(:scan) #=> true etc.
Pretty much just a stripped down subblock class to handle these. I think our IAR/C compilers and even CATI could benefit from this and make the setup cleaner and more customizable.
Context
I'm building my complete debian system configuration,
so I'm modifying the keyboard and console setups.
I prefer not to modify the base files to keep a maximum
commpatibility and modularity. So I want to use VARIANT
(see setupcon (5)) and load them at init.
But not sure I'm doing it right.
Desired Architecture
I will only use keyboard file for the following example.
There is the base file /etc/default/keyboard
And two possible custom files (according to setupcon (5))
~/.keyboard
/etc/default/keyboard.variant
~/.keyboard
It provides a custom behaviour per $HOME (user)
/etc/default/keyboard.variant
A global and default keyboard setup
I would like to use the three at a time.
Problem
The daemon calling setupcon are console-setup and console-setup-mini
(according to the coments in their initd scripts). They are started
before login shell, so won't know ~/.keyboard.
setupcon needs to be called
setupcon variant
or, looking at the sources, with a variable $VARIANT
VARIANT=variant
What is the best solution to adopt, saving a maximum modularity.
Thank you,
All standards compliant applications in Linux store a desktop schema in /usr/share/applications/. In my particular use case, I have a WnckWindow data structure and I can get a pid from that. Using this pid, I can extract the command line from the proc.
Unfortunately, it seems that the proc command line entry does not match the desktop schema launch parameters. For example, the 'thunderbird' application is launched via /usr/bin/thunderbird but this is just a shell script which activates the real executable: /usr/lib/thunderbird-8.0/thunderbird-bin.
The real executable cannot be launched directly as it is dependent on the library paths configured in the /usr/bin/thunderbird script. Does anyone have any advice on how to match process id numbers to the appropriate desktop schema without getting caught by the issue I've described?, Thanks.
Ok, well, it appears that there's no nice way of solving this using the pid, however, it is relatively easy to match the Wnck windows class to application desktop schemas. The Wnck windows class needs to be preprocessed a little first to ensure that the filter works but it's pretty trivial stuff. Once you've got a good set of target strings, eg 'Thunderbird' or 'Google' + 'Chrome', you can use the system application menu API to zero in on a likely candidate, for example, by using garcon on Xfce.