как узнать путь до скрипта из него самого

[logic 51]

раньше использовал os.getenv("_") но затем окозалось что в rc это не катит(моя модификация rc делает os.setenv("_", path) а стандартная нет)

да и на бибилтеки тоже не катит хотя и библиотеки могут состоять из нескольких файлов использовать это не реально из за этого ограницения

так как быть? есть ли "легальный" способ узнать где лежит скрипт?

[ECS 1 901]

3 часа назад, rootmaster сказал:

раньше использовал os.getenv("_") но затем окозалось что в rc это не катит(моя модификация rc делает os.setenv("_", path) а стандартная нет)

да и на бибилтеки тоже не катит хотя и библиотеки могут состоять из нескольких файлов использовать это не реально из за этого ограницения

Ты используешь getenv не по назначению, отсюда и проблемы. При инициализации библиотек путь к ним не записывается в env, при запуске файлов вручную через filesystem proxy тоже, при чтении rc.d тоже. Это скорее прикладная софтверная фича OpenOS, которую удобно юзать при работе с shell для получения быстрых путей к переменным окружения, и она вовсе не является частью API файловой системы, как может показаться. Поэтому при исполнении файла через shell.execute env будет обновлен, а при исполнении через dofile/loadfile - нет

 

3 часа назад, rootmaster сказал:

так как быть? есть ли "легальный" способ узнать где лежит скрипт?

OpenOS:

shell.resolve(process.info().path)

MineOS:

system.getCurrentScript()

Что угодно, включая EEPROM:

local function getCurrentScriptPath()
  local info

  for runLevel = 0, math.huge do
    info = debug.getinfo(runLevel)

    if info then
      if info.what == "main" then
        return info.source:sub(2, -1)
      end
    else
      error("Failed to get debug info for runlevel " .. runLevel)
    end
  end
end

 

[logic Автор вопроса 51]

4 часа назад, ECS сказал:

Ты используешь getenv не по назначению, отсюда и проблемы. При инициализации библиотек путь к ним не записывается в env, при запуске файлов вручную через filesystem proxy тоже, при чтении rc.d тоже. Это скорее прикладная софтверная фича OpenOS, которую удобно юзать при работе с shell для получения быстрых путей к переменным окружения, и она вовсе не является частью API файловой системы, как может показаться. Поэтому при исполнении файла через shell.execute env будет обновлен, а при исполнении через dofile/loadfile - нет

 

OpenOS:

shell.resolve(process.info().path)

MineOS:

system.getCurrentScript()

Что угодно, включая EEPROM:

local function getCurrentScriptPath()
  local info

  for runLevel = 0, math.huge do
    info = debug.getinfo(runLevel)

    if info then
      if info.what == "main" then
        return info.source:sub(2, -1)
      end
    else
      error("Failed to get debug info for runlevel " .. runLevel)
    end
  end
end

 

для openOS нерабочую конструкцию дал, она возвращает первую часть команды которая была выполнена в следствии чего открылась прога