This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Getting wind data into Pypilot
#41
Hmm,

I use 'sh ./pypilot.build' and it works quite fine. I never tried '. pypilot.build' but I will, and try to see if it fails.

As for 'many things are still broken on that image' can you be more specific ? I, and others, use this image without any obvious problems...
Reply
#42
I think LIRC and some of the programs I like to use (such as emacs) but none of this is significant for most users.

It seems very odd that ". pypilot.build" isnt working and I don't understand what changed or if it could impact anything else.

Everything else that is not working is not specific to your image... I am finally able to work on the software a bit so there are numerous problems, but its getting better.
Reply
#43
Yes, LIRC does not work because kernel interface has changed, and, since I only use RF remotes and not IR ones, I haven't tried enough to fix this...

As for emacs, as you might guess, I'm a vi user Smile . So maybe I have commented this out in the startup script, or have not downloaded the tcz, I don't know. But it should be easy to fix.

I will look into the 'sh source' issue.
Reply
#44
Yes, I may not really support IR remotes much longer, so its not really important. The kernel interface changed but so did lirc, and so did pylirc, and none of it works as well as the old version for me anyway.

Dont worry about the emacs at all. It is easy to fix. It should not load the dev tools until everything is booted so it should not negatively impact anyone to have these in the startup script... let me know if you needed to comment emacs out. I have no issues with vi, or at least no issues with other people using it, and maybe it would make sense to have it available as well. I just noticed emacs didnt work and wondered what else was not installed, maybe nothing. Sorry its taken me so long to get around to this.

The sh source may be nothing.. but I also wonder why it changed and what implications this could have.
Reply
#45
I just have tried, and '. ./pypilot.build' works just fine here. Notice the './pypilot.build', instead of just 'pypilot.build'. Not sure this worked before because, at least in 'bash' man page, it is stated that 'source' searches the file in PATH. Of course, on tinycore it's busybox sh, not sure if the older version searched in the current directory as well (or maybe you just happen to have '.' in PATH, which is bad practice in general)

One thing that might go wrong is running the script too early, before the dev tools are loaded. And I also have seen strange (rebuild) issues when the system date is not correctly set up (from GPS or NTP for example). And also, make sure everything is owned by 'tc : staff', if you did builds as root before, some files will be owned by root, and the rebuild process will not be able to rewrite these files with the new content (use 'find . -owner root')

As for emacs, it looks like it needs libncursesw.so.5 which is inexistent in tinycore repo. Either this has not been rebuilt yet, or the emacs package needs to be rebuild with the newer libncurses. Anyway, it is not commented out, and yes, it loads at the very end of the boot.
Reply
#46
it should work with just . I think the "." represents the current directory. It works on my other systems. You can put in a file "echo hi" and invoke with ". script" normally anyway. This is without . in the path, or the current directory in the path.

Anyway.. if this is the only effect in a new version of busy box it is ok, just peculiar.

I normally do not build as root.. for reasons you said. The date issue is a bit annoying since it sometimes is just way off and no way to correct it without gps or ntp (and ntp is not really relied on for tinypilot)

Yes, the issue with emacs is the ncurses library version. There is a newer version of ncurses so emacs probably just needs to to be rebuilt.
Reply
#47
You are correct, it works in bash. In fact the man page states (I have read a bit too quickly):
Read and execute commands from filename in the current shell en‐
vironment and return the exit status of the last command exe‐
cuted from filename. If filename does not contain a slash,
filenames in PATH are used to find the directory containing
filename. The file searched for in PATH need not be executable.
When bash is not in posix mode, the current directory is
searched if no file is found in PATH.

Anyway, on tinypilot 13:
tc@pypilot:~$ echo "echo hi" > foo
tc@pypilot:~$ . foo
-sh: .: foo: not found
tc@pypilot:~$ . ./foo
hi

A quick search about this ended up on this discussion https://busybox.busybox.narkive.com/tfMJ...after-path . It's from 5 years ago, when devs struggled to decide whether to keep the current directory on the search list (seems to be a bashism) or to follow POSIX. I'd say they finally settled up on the latter, although I'm too lazy right now to find the exact change in busybox github...

This is not the only effect of the new busybox however, 'timeout' syntax did change as well (see https://github.com/pypilot/pypilot/pull/119). And maybe others, who knows...
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)